Langage de modélisation (UML) - TD4

Partie A - Diagramme d'interaction

Exercice 1 - Affectation des Freelancers

Question 1 - Diagramme de séquences objets (Ajouter Affectation)

Pour construire ce diagramme, nous devons d'abord identifier les éléments principaux à partir de l'énoncé :

• Acteur : Le Directeur des Ressources Humaines (DRH).
• Objets/Classes participant : Le Système (ou Interface), la liste des missions, la liste des freelancers, le planning du freelancer, et l'objet Affectation.
• Logique conditionnelle (Alt) : La vérification de la disponibilité. Si le freelancer est disponible, on crée l'affectation ; sinon, on affiche une erreur.

Raisonnement pas à pas :

1. Le DRH demande à consulter les missions. Le système interroge la liste des missions et les renvoie.
2. Le DRH choisit une mission.
3. Le DRH consulte la liste des freelancers. Le système recherche ceux ayant les compétences requises et les affiche.
4. Le DRH choisit un freelancer.
5. Le système vérifie le planning de ce freelancer.
6. Un bloc alt (alternative) est utilisé pour le chevauchement :
   • Cas succès : Mise à jour du planning, création de l'affectation (date début, date fin).
   • Cas échec : Retour d'un message d'erreur au DRH.

Voici le code PlantUML correspondant, que vous pouvez utiliser pour générer le diagramme :

@startuml
actor DRH
participant "Interface : Systeme" as Sys
participant "missions : ListeMissions" as LM
participant "freelancers : ListeFreelancers" as LF
participant "planning : Planning" as Plan

DRH -> Sys : consulterMissions()
Sys -> LM : getMissions()
LM --> Sys : liste des missions
Sys --> DRH : afficher missions

DRH -> Sys : choisirMission(mission)

DRH -> Sys : consulterFreelancers()
Sys -> LF : getFreelancers(competences)
LF --> Sys : liste des freelancers
Sys --> DRH : afficher freelancers

DRH -> Sys : choisirFreelancer(freelancer)
Sys -> Plan : verifierDisponibilite(dateDebut, dateFin)
Plan --> Sys : estDisponible

alt estDisponible == vrai
    Sys -> Plan : majPlanning()
    create participant "nouvelle : Affectation" as Aff
    Sys -> Aff : new(dateDebut, dateFin, mission, freelancer)
    Sys --> DRH : confirmation affectation
else chevauchement
    Sys --> DRH : afficherErreur("Chevauchement de dates")
end
@enduml

Question 2 - Diagramme de communication

Le diagramme de communication représente exactement les mêmes interactions que le diagramme de séquence, mais en mettant l'accent sur la structure des liens entre les objets plutôt que sur le temps (chronologie de haut en bas). L'ordre chronologique est ici donné par la numérotation des messages.

Séquence des messages numérotés :

• 1 : consulterMissions()
• 1.1 : getMissions()
• 2 : choisirMission(mission)
• 3 : consulterFreelancers()
• 3.1 : getFreelancers(competences)
• 4 : choisirFreelancer(freelancer)
• 4.1 : verifierDisponibilite()
• 4.2 [estDisponible] : majPlanning()
• 4.3 [estDisponible] : create(dateDebut, dateFin, ...)
• 4.4 [non estDisponible] : afficherErreur()

@startuml
actor DRH
object "Interface : Systeme" as Sys
object "missions : ListeMissions" as LM
object "freelancers : ListeFreelancers" as LF
object "planning : Planning" as Plan
object "nouvelle : Affectation" as Aff

DRH -right- Sys : 1: consulterMissions()\n2: choisirMission()\n3: consulterFreelancers()\n4: choisirFreelancer()
Sys -up- LM : 1.1: getMissions()
Sys -down- LF : 3.1: getFreelancers(competences)
Sys -right- Plan : 4.1: verifierDisponibilite()\n4.2 [disponible]: majPlanning()
Sys -down- Aff : 4.3 [disponible]: create(...)
@enduml

Exercice 2 - Le Baladeur Numérique

Question 1 - Comportement interne du baladeur

Ici, nous concevons le diagramme sans notion d'architecture logicielle complexe. L'interface ("Baladeur") gère directement la logique métier.

• Acteur : Utilisateur.
• Objets : Baladeur, CatalogueAlbums, l'Album trouvé, la nouvelle ListeLecture.
• Boucle (Loop) : L'énoncé précise "ajoute un à un tous les morceaux". Une boucle est donc indispensable.

@startuml
actor Utilisateur
participant "Baladeur" as B
participant "CatalogueAlbums" as CA
participant "al : Album" as Al
participant "nouvelleListe : ListeLecture" as LL

Utilisateur -> B : ajouterAlbumNouvelleListe(nomAlbum, nomListe)
B -> CA : chercherAlbum(nomAlbum)
CA --> B : al

create LL
B -> LL : new(nomListe)

B -> Al : listeMorceaux = getMorceaux()
Al --> B : listeMorceaux

loop pour chaque morceau m dans listeMorceaux
    B -> LL : ajouterMorceau(m)
end
@enduml

Question 2 - Architecture en 3 couches

L'architecture 3 tiers (ou 3 couches) sépare strictement :

1. Présentation (Vue/IHM) : Gère l'interaction avec l'utilisateur.
2. Métier (Contrôleur/Service) : Contient la logique applicative.
3. Données (Modèle/DAO) : Gère l'accès aux données persistantes.

L'acteur n'interagit qu'avec la Vue. La Vue n'interagit qu'avec le Contrôleur. Le Contrôleur interagit avec les Données.

@startuml
actor Utilisateur
participant "IHM : Vue" as Vue
participant "ControleurBaladeur : Metier" as Ctrl
participant "BaseDeDonnees : AccesDonnees" as BD

Utilisateur -> Vue : ajouterAlbumNouvelleListe(nomAlbum, nomListe)
Vue -> Ctrl : ajouterAlbumListe(nomAlbum, nomListe)

Ctrl -> BD : album = chercherAlbum(nomAlbum)
BD --> Ctrl : donneesAlbum

Ctrl -> BD : creerListeLecture(nomListe)
BD --> Ctrl : idListe

Ctrl -> BD : morceaux = getMorceauxAlbum(album)
BD --> Ctrl : listeMorceaux

loop pour chaque morceau m
    Ctrl -> BD : ajouterMorceauListe(idListe, m)
end

Ctrl --> Vue : confirmation
Vue --> Utilisateur : afficherSucces()
@enduml

Exercice 3 - Application d'échange de services

Question 1 - Ajouter un service (Architecture 3 couches)

L'énoncé demande à nouveau une architecture 3 couches.

• Acteur : Membre (il est authentifié, on suppose cela fait).
• Cinématique : Le membre choisit une catégorie, puis une sous-catégorie, puis valide les informations du service.
• Vérification : Le contrôleur doit vérifier les données. Si valide, enregistrement et succès. Sinon, échec.

@startuml
actor Membre
participant "InterfaceService : Vue" as Vue
participant "GestionService : Controleur" as Ctrl
participant "BDD : AccesDonnees" as BD

Membre -> Vue : consulterCategories()
Vue -> Ctrl : getCategories()
Ctrl -> BD : getCategories()
BD --> Ctrl : listeCategories
Ctrl --> Vue : listeCategories
Vue --> Membre : afficher categories

Membre -> Vue : choisirCategorie(cat)
Membre -> Vue : choisirSousCategorie(sousCat)
Membre -> Vue : creerService(desc, termeEchange, dateD, dateF)

Vue -> Ctrl : ajouterService(membre, cat, sousCat, desc, terme, dateD, dateF)

Ctrl -> Ctrl : verifierDonnees()

alt données valides
    Ctrl -> BD : insererService(...)
    BD --> Ctrl : ok
    Ctrl --> Vue : succes
    Vue --> Membre : afficher message succes
else données invalides
    Ctrl --> Vue : erreur
    Vue --> Membre : afficher message erreur d'ajout
end
@enduml

Question 2 - Diagramme de communication (Ajouter un service)

La numérotation respecte la hiérarchie de l'architecture en couches.

@startuml
actor Membre
object "InterfaceService : Vue" as Vue
object "GestionService : Controleur" as Ctrl
object "BDD : AccesDonnees" as BD

Membre -right- Vue : 1: consulterCategories()\n2: choisirCategorie()\n3: choisirSousCategorie()\n4: creerService()
Vue -right- Ctrl : 1.1: getCategories()\n4.1: ajouterService()
Ctrl -down- BD : 1.1.1: getCategories()\n4.1.1 [donnees valides]: insererService()
@enduml

Partie B - Diagramme état transition

Exercice 4 - Boîte de vitesses automatique

Règles extraites de l'énoncé :

• État initial : Point mort.
• Depuis le Point mort : Marche arrière, Parking, Première marche avant (1).
• Accélération : 1 -> 2 -> 3.
• Décélération : 3 -> 2 -> 1.
• Retour au Point mort direct uniquement depuis : Marche arrière, Parking, et Première marche avant (1). Les vitesses 2 et 3 ne peuvent pas revenir directement au point mort (elles doivent d'abord décélérer jusqu'à 1).

@startuml
[*] --> PointMort

PointMort --> MarcheArriere : enclencher marche arrière
MarcheArriere --> PointMort : revenir au point mort

PointMort --> Parking : positionner parking
Parking --> PointMort : revenir au point mort

PointMort --> Avant1 : enclencher 1ère
Avant1 --> PointMort : revenir au point mort

Avant1 --> Avant2 : acceleration
Avant2 --> Avant3 : acceleration

Avant3 --> Avant2 : deceleration
Avant2 --> Avant1 : deceleration
@enduml

Exercice 5 - Montre à cadran numérique

Question 1 - Diagramme d'états de base

Les transitions sont basées sur deux boutons : mode et avance.

• États : Affichage, ModificationHeure, ModificationMinute.

@startuml
[*] --> Affichage

Affichage --> ModificationHeure : bouton mode
ModificationHeure --> ModificationHeure : bouton avance / incrementer(heure)
ModificationHeure --> ModificationMinute : bouton mode
ModificationMinute --> ModificationMinute : bouton avance / incrementer(minute)
ModificationMinute --> Affichage : bouton mode
@enduml

Question 2 - Comportement de l'incrémentation rapide

L'énoncé demande d'envisager plusieurs solutions possibles. En modélisation UML, deux approches principales se dégagent pour gérer un "appui long".

Solution A : Ajout de sous-états explicites (États composites) On crée deux états distincts pour la modification : un état pour l'attente du bouton (ou l'appui court) et un état pour l'appui continu.

• Transition vers l'incrémentation rapide déclenchée par un garde [pression bouton > 2s].
• Dans l'état rapide, une transition interne after(dt) génère des incrémentations régulières.
• Le relâchement ramène à l'état de modification de base.

Solution B : Utilisation d'un événement temporel (Time Event) dans le même état On conserve les mêmes états principaux, mais on utilise des transitions internes avec des délais. Une transition se déclenche si le bouton est maintenu enfoncé.

Dans le cadre d'un examen de modélisation, la Solution A (états séparés) est souvent plus claire car elle explicite les changements de comportement de la montre. Voici la modélisation de la Solution A (appliquée ici à l'heure, identique pour les minutes) :

@startuml
[*] --> Affichage

Affichage --> ModifHeure : mode

state ModifHeure {
    [*] --> AttenteHeure
    AttenteHeure --> AttenteHeure : avance [appui < 2s] / inc(H)
    AttenteHeure --> AvanceRapideHeure : avance [maintenu > 2s]
    AvanceRapideHeure --> AvanceRapideHeure : tick / inc(H)
    AvanceRapideHeure --> AttenteHeure : relachement avance
}

ModifHeure --> ModifMinute : mode

state ModifMinute {
    [*] --> AttenteMin
    AttenteMin --> AttenteMin : avance [appui < 2s] / inc(M)
    AttenteMin --> AvanceRapideMin : avance [maintenu > 2s]
    AvanceRapideMin --> AvanceRapideMin : tick / inc(M)
    AvanceRapideMin --> AttenteMin : relachement avance
}

ModifMinute --> Affichage : mode
@enduml

Question 3 - Diagramme d'états complet (Régions orthogonales)

La montre possède maintenant des fonctionnalités parallèles :

1. La gestion de l'heure (Affichage / Modification).
2. L'éclairage (indépendant de la modification de l'heure).
3. L'alarme (activée/désactivée/sonnerie).

Pour représenter des comportements concurrents en UML, nous utilisons des régions orthogonales (séparées par des lignes en pointillés ou par le symbole -- en PlantUML) à l'intérieur d'un état composite englobant le système "Montre".

@startuml
state Montre {

  state GestionHeureEtDate {
    [*] --> Affichage
    Affichage --> ModifHeure : mode
    ModifHeure --> ModifHeure : avance / inc(H)
    ModifHeure --> ModifMinute : mode
    ModifMinute --> ModifMinute : avance / inc(M)
    ModifMinute --> Affichage : mode
    ' Note : La simplification de la Q1 est utilisée ici pour la lisibilité
  }

  --

  state GestionEclairage {
    [*] --> Eteint
    Eteint --> Allume : presser eclairage
    Allume --> Eteint : relacher eclairage
  }

  --

  state GestionAlarme {
    [*] --> AlarmeDesactivee
    AlarmeDesactivee --> AlarmeActivee : bouton alarme
    AlarmeActivee --> AlarmeDesactivee : bouton alarme
    AlarmeActivee --> Sonnerie : heureCourante == heureAlarme
    Sonnerie --> AlarmeActivee : bouton alarme (arreter)
    Sonnerie --> AlarmeActivee : after(duree_max)
  }

}
@enduml

Méthode

Face à une épreuve de conception dynamique UML (Séquence, Communication, États-transitions) :

1. Identifiez systématiquement les acteurs et les objets : Avant de tracer la moindre flèche, soulignez dans le texte qui fait l'action (l'acteur) et quelles entités du système sont impactées (objets, bases de données, listes).
2. Respectez l'architecture imposée : Si l'énoncé précise "architecture en 3 couches", vos diagrammes de séquence doivent impérativement montrer un objet IHM (Vue), un objet Métier (Contrôleur) et un objet de persistance (Base/Modèle). Un acteur ne doit jamais attaquer directement la base de données.
3. Tracez les chemins alternatifs (alt, opt, loop) : Un diagramme de séquence n'est pas qu'un cas idéal. Dès que le texte mentionne "S'il est disponible", "Une vérification est effectuée", ou "Pour chaque", intégrez les fragments combinés correspondants.
4. Diagrammes d'états : isolez les variables d'état : Un état représente une situation stable entre deux événements. Vérifiez toujours que chaque flèche sortante est déclenchée par un événement précis (un bouton, une condition temporelle, un signal).
5. Gérez la concurrence (orthogonalité) : Si plusieurs fonctionnalités opèrent de manière indépendante (comme l'éclairage qui fonctionne que l'on modifie l'heure ou non), encapsulez le système complet et divisez-le en sous-régions parallèles. Tenter de fusionner ces états (ex: AffichageEclairé, ModifHeureEclairé) conduit à une explosion combinatoire des états, ce qui est considéré comme une erreur de modélisation.