Correction of Dynamic Modeling Exercises

Exercice 1 - Inscription d'un membre à un cours privé

Le texte source omet les schémas des diagrammes de la solution, ne laissant que l'espace vide. En tant que concepteur, voici la reconstruction étape par étape des éléments que vous deviez inclure dans vos diagrammes de séquence et de collaboration pour obtenir la note maximale.

Identification des éléments du système

Avant de tracer un diagramme dynamique, il faut identifier l'acteur et les objets (instances de classes) impliqués, selon le modèle d'analyse MVC (Modèle-Vue-Contrôleur) ou BCE (Boundary-Control-Entity) classique :

• Acteur : Préposé aux inscriptions
• Interface (Vue/Boundary) : :PageInscription
• Contrôleur (Optionnel mais recommandé) : :ContrôleurInscription (Nous utiliserons un contrôleur implicite ou le système de manière globale pour simplifier, mais décomposer est mieux).
• Entités (Modèle) : :RépertoireProfs, prof:Professeur, :Planning, plage:PlageDeCours, :RépertoireMembres, membre:Membre, :SystèmeFacturation.

Diagramme de séquence - Déroulement chronologique

Le diagramme de séquence se lit de haut en bas. Voici les messages (méthodes) qui doivent apparaître sur votre copie, dans cet ordre strict, avec leurs paramètres :

1. Le Préposé envoie saisirInfos(typeCours, nomProf) à l'objet :PageInscription.
2. L'interface transmet (via le contrôleur) le message chercher(nomProf) à l'objet :RépertoireProfs.
3. Le répertoire retourne l'objet prof:Professeur.
4. Le système envoie chercherPlageLibre() au :Planning lié à ce prof.
5. Une fois la disponibilité trouvée, le système instancie une nouvelle plage temporelle : message de création new(horaire) vers plage:PlageDeCours.
6. Le système envoie ajouterPlage(plage) au :Planning.
7. Le système envoie afficherRésultat(cours, prof, horaire) en retour à la :PageInscription.
8. Le Préposé lit le résultat, puis envoie saisirNom(nomMembre) et cliquerConfirmer() à la :PageInscription.
9. Le système envoie chercher(nomMembre) au :RépertoireMembres, qui retourne l'objet membre:Membre.
10. Le système envoie assignerPlage(plage) à l'objet membre:Membre.
11. Le système interagit avec un autre cas d'utilisation (inclusion) : il envoie un message facturer(cours, membre) au :SystèmeFacturation.
12. Le système envoie afficherMessage("Confirmation réussie") à la :PageInscription.

Diagramme de collaboration - Déroulement spatial

Le diagramme de collaboration (ou diagramme de communication en UML 2) utilise exactement les mêmes objets et les mêmes messages que ci-dessus, mais met en évidence l'architecture réseau ou spatiale des objets plutôt que le temps. Sur votre copie, les objets sont reliés par des traits (liens) sur lesquels circulent les messages, précédés d'un numéro d'ordre hiérarchique :

• 1 : saisirInfos(...)
• 1.1 : chercher(...)
• 1.2 : chercherPlageLibre()
• 1.3 : new()
• 1.4 : ajouterPlage(...)
• 1.5 : afficherRésultat(...)
• 2 : saisirNom(...)
• 3 : cliquerConfirmer()
• 3.1 : chercher(...)
• 3.2 : assignerPlage(...)
• 3.3 : facturer(...)
• 3.4 : afficherMessage(...)

L'erreur la plus courante ici est d'oublier que la création de la plage (étape 3 du scénario) précède la confirmation du membre (étape 4), ce qui nécessite bien deux phases d'interaction distinctes avec l'acteur sur l'interface.

Exercice 2 - Modélisation de la montre numérique

Ce problème exige un diagramme d'état-transition (ou diagramme d'états). La montre est un système réactif simple guidé par des événements (pression de boutons).

Définition des états

• État initial : Représenté par un point noir plein, il pointe avec une flèche vers l'état par défaut.
• État 1 : Affichage (L'énoncé précise : "Le mode courant est le mode Affichage").
• État 2 : Modification Heure.
• État 3 : Modification Minute.

Définition des transitions

Sur votre diagramme, chaque flèche entre les états doit être étiquetée avec la syntaxe Événement [Condition] / Action.

1. De l'état initial vers Affichage :
   • Transition automatique (pas d'événement).
2. De Affichage vers Modification Heure :
   • Événement : appui bouton mode.
3. Boucle sur Modification Heure (Auto-transition) :
   • Événement : appui bouton avance.
   • Action : / incrémenter heure.
   • Note de correction : L'état ne change pas, la flèche part de l'état et y revient.
4. De Modification Heure vers Modification Minute :
   • Événement : appui bouton mode.

Boucle sur Modification Minute (Auto-transition) :

• Événement : appui bouton avance.
• Action : / incrémenter minutes.

De Modification Minute vers Affichage :

• Événement : appui bouton mode.

Si vous avez ajouté des gardes pour gérer le passage de 23h à 00h ou de 59 min à 00 min (ex: [heure < 23] / heure = heure + 1 et [heure = 23] / heure = 0), c'est un excellent réflexe de conception, bien que l'énoncé simplifié ne l'exige pas explicitement pour avoir les points.

Exercice 3 - Retrait d'argent avec carte VISA

Le diagramme d'activités modélise le flux de contrôle. La difficulté de cet exercice réside dans la gestion des erreurs (carte invalide, code faux, carte avalée) et le parallélisme explicite ("Un ticket est toujours imprimé pendant que les billets sont proposés").

Parcours de modélisation pas-à-pas

1. Début : Point noir initial.
2. Action 1 : Vérifier la validité de la carte.
3. Branchement (Losange de décision) :
   • Condition [Carte invalide] -> Action Avaler la carte -> État final (point noir entouré d'un cercle).
   • Condition [Carte valide] -> Action Saisir le code PIN.
4. Boucle de saisie et vérification du code :
   • Action : Vérifier code.
   • Losange de décision :
     • Condition [Code faux ET essais < 3] -> Retour à l'action Saisir le code PIN.
     • Condition [Code faux ET essais = 3] -> Action Avaler la carte -> État final.
     • Condition [Code correct] -> Action Demander autorisation au SA VISA.
5. Autorisation bancaire :
   • Losange de décision en sortie d'autorisation :
     • Condition [Retrait refusé] -> Action Éjecter la carte -> État final.
     • Condition [Retrait autorisé] -> Barre de synchronisation (Fork) pour séparer le flux en deux tâches parallèles.

Exécution parallèle (les deux branches partent de la barre Fork) :

• Branche A : Action Imprimer ticket.
• Branche B : Action Proposer billets.
  • À la suite de cette action, un losange de décision s'impose (gestion du non-retrait) :
  • Condition [Billets récupérés] -> (suite).
  • Condition [Timeout : Billets non récupérés] -> Action Reprendre les billets -> (suite).

Synchronisation : Les branches A et B rejoignent une barre de synchronisation (Join).

Fin de transaction :

• Action : Éjecter la carte.
• Losange de décision :
  • Condition [Carte récupérée] -> État final.
  • Condition [Timeout : Carte non récupérée] -> Action Avaler la carte -> État final.

Attention : L'ordre entre l'éjection de la carte et la distribution des billets peut varier selon les guichets dans la réalité, mais la règle stricte du diagramme d'activités est de respecter l'énoncé. L'énoncé indique l'impression pendant que les billets sont proposés, justifiant la barre de parallélisme (fork/join).

Méthode

Pour réussir ce type d'épreuve de modélisation dynamique (UML) :

• Identifiez les mots-clés du sujet : Les noms propres et communs définissent généralement les Objets et les Classes. Les verbes d'action définissent les Messages (diagrammes de séquence/collaboration) ou les Activités (diagramme d'activités).
• Ne laissez pas de culs-de-sac : Dans les diagrammes d'états ou d'activités, chaque chemin d'erreur (carte muette, code erroné, absence d'action du client) doit mener explicitement à une résolution ou à un état final.
• Respectez le paradigme du diagramme : Ne mettez pas de conditions de garde [ ] sur des lignes de vie temporelles (séquence) à moins d'utiliser des blocs combinés (Alt/Opt). Inversement, n'utilisez pas de flux chronologiques numérotés dans un diagramme d'états.
• Séparez les responsabilités : Un acteur n'interagit pas directement avec une base de données. Il interagit avec une interface utilisateur (page, écran), qui elle-même interroge le système ou le contrôleur. Garder cette séparation vous assurera la validation des correcteurs sur l'architecture de votre solution.