Correction de la série N°4: Modélisation dynamique

Ce document présente la correction d’une série d’exercices en modélisation dynamique, destinée à évaluer les compétences en analyse et conception de systèmes informatiques à travers des diagrammes UML (séquence, collaboration, états-transitions, activités). Chaque exercice propose un cas pratique à modéliser, avec des solutions détaillées permettant de comprendre les étapes et la logique sous-jacente.

Exercice 1 : Diagramme de séquence pour un retrait DABB

La modélisation du déroulement normal du cas d’utilisation de retrait d’argent auprès d’un distributeur automatique s'effectue en ne considérant que le scénario où tout se déroule sans erreur.

Le scénario décrit les interactions suivantes :

• Le client introduit sa carte bancaire.
• La machine vérifie la validité de la carte et demande le code au client.
• Si le code est correct, la machine envoie une demande d’autorisation de prélèvement au système bancaire, qui renvoie le solde autorisé.
• Le distributeur propose plusieurs montants à prélever.
• Le client saisit le montant à retirer, qui est contrôlé par rapport au solde autorisé.
• Le distributeur demande si le client souhaite un ticket.
• Après la réponse, la carte est éjectée et récupérée par le client.
• Les billets (et éventuellement le ticket) sont délivrés.
• Le client récupère les billets et le ticket.

Pour modéliser cela dans un diagramme de séquence, on représente les objets suivants : Client, Distributeur, Système d’autorisation bancaire.

Les messages échangés sont :

1. Client à Distributeur : introduireCarte()
2. Distributeur à Distributeur : vérifierValiditéCarte()
3. Distributeur à Client : demanderCode()
4. Client à Distributeur : saisirCode()
5. Distributeur à Distributeur : vérifierCode()
6. Distributeur à SystèmeAutorisation : demanderAutorisation()
7. SystèmeAutorisation à Distributeur : soldeAutorisé()
8. Distributeur à Client : proposerMontants()
9. Client à Distributeur : saisirMontant()
10. Distributeur à Distributeur : contrôlerMontant()
11. Distributeur à Client : demanderTicket()
12. Client à Distributeur : réponseTicket()
13. Distributeur à Client : éjecterCarte()
14. Client à Distributeur : récupérerCarte()
15. Distributeur à Distributeur : délivrerBillets()
16. Distributeur à Distributeur : délivrerTicket() (si demandé)
17. Client à Distributeur : récupérerBilletsEtTicket()

Réponse : Le diagramme de séquence doit représenter ces échanges dans cet ordre, illustrant clairement le flux normal sans erreurs ni exceptions.

Exercice 2 : Inscription à un cours privé

La conception des diagrammes de séquence et de collaboration permet d'illustrer le cas d’utilisation « Inscription d’un membre à un cours privé » dans un club de sport.

Le scénario principal est le suivant :

1. Le préposé entre le type de cours et le nom du professeur.
2. Le système recherche le professeur dans le répertoire, puis une plage horaire libre où le professeur est disponible et non réservée.
3. Si une plage est disponible, le système l’ajoute au planning du professeur en attente de confirmation et affiche le résultat.
4. Si la plage convient, le préposé saisit le nom du membre et confirme.
5. Le système cherche le membre dans le répertoire et lui assigne la plage de cours.
6. Le cours est facturé au membre (inclusion du cas « Facturation d’un cours »).
7. Le système confirme l’inscription par un message.

Diagramme de séquence

• Acteurs : Préposé, Système (avec sous-objets : RépertoireProfesseurs, RépertoireMembres, Planning, Facturation).
• Messages principaux :
  • Préposé à Système : saisirTypeCoursEtProfesseur()
  • Système à RépertoireProfesseurs : chercherProfesseur(nom)
  • RépertoireProfesseurs à Système : professeur
  • Système à Planning : chercherPlageLibre(professeur)
  • Planning à Système : plageDisponible
  • Système à Préposé : afficherPlage(plageDisponible)
  • Préposé à Système : saisirNomMembre()
  • Préposé à Système : confirmerInscription()
  • Système à RépertoireMembres : chercherMembre(nom)
  • RépertoireMembres à Système : membre
  • Système à Planning : assignerPlage(membre, plage)
  • Système à Facturation : facturerCours(membre, cours)
  • Facturation à Système : confirmationFacturation
  • Système à Préposé : afficherMessageConfirmation()

Diagramme de collaboration

• Met en évidence les liens entre objets : Préposé, Système, RépertoireProfesseurs, RépertoireMembres, Planning, Facturation.
• Les messages sont numérotés dans l’ordre du scénario, illustrant les interactions.

Réponse : Les diagrammes doivent refléter ce flux d’interactions, montrant clairement la recherche, la réservation, la confirmation et la facturation.

Exercice 3 : Diagramme d’état-transition d'une montre numérique

Un diagramme d’état-transition permet de représenter le fonctionnement d'une montre numérique simplifiée possédant trois modes principaux.

Les modes et comportements à modéliser sont :

• Mode « Affichage » (mode courant).
• Appui sur le bouton mode : passage en « modification heure ».
• Chaque pression sur le bouton avance incrémente l’heure d’une unité.
• Nouvel appui sur mode : passage en « modification minute ».
• Chaque pression sur le bouton avance incrémente les minutes d’une unité.
• Nouvel appui sur mode : retour en mode « Affichage ».

Étapes pour construire le diagramme d’état-transition :

1. Définir les états : Affichage, ModificationHeure, ModificationMinute.
2. Transitions sur événement « appui bouton mode » :
   • Affichage vers ModificationHeure
   • ModificationHeure vers ModificationMinute
   • ModificationMinute vers Affichage
3. Transitions sur événement « appui bouton avance » :
   • Dans ModificationHeure : incrémenter heure
   • Dans ModificationMinute : incrémenter minute

Réponse : Le diagramme d’état-transition comporte trois états en cycle avec les transitions décrites, illustrant clairement les changements de mode et les actions associées.

Exercice 4 : Dispositif de contrôle d’accès par carte

Le diagramme d’états-transitions du dispositif de contrôle d’accès par carte magnétique modélise les messages affichés en fonction de l’état du système.

Les états et affichages associés sont :

• État initial : « INSEREZ VOTRE CARTE » (dispositif inutilisé).
• Après insertion, état « PATIENTER » pendant la lecture du code.
• Si code illisible : « CARTE INVALIDE », puis éjection automatique.
• Si code lu : « COMPOSEZ VOTRE CODE ».
• Si code refusé : « CODE REFUSE », puis éjection automatique.
• Si code correct : « UTILISATION EN COURS ».
• À tout moment, le bouton éjection provoque l'éjection de la carte et le retour à « INSEREZ VOTRE CARTE ».

Étapes pour le diagramme :

1. État « Inactif » : affiche « INSEREZ VOTRE CARTE ».
2. Transition insertion carte vers état « LectureCode » : affiche « PATIENTER ».
3. Lecture du code :
   • Si code illisible : état « CarteInvalide » avec affichage « CARTE INVALIDE », éjection automatique et retour à « Inactif ».
   • Sinon : état « SaisieCode » avec affichage « COMPOSEZ VOTRE CODE ».
4. Dans « SaisieCode » :
   • Si code incorrect : état « CodeRefuse » avec affichage « CODE REFUSE », éjection automatique et retour à « Inactif ».
   • Si code correct : état « Utilisation » avec affichage « UTILISATION EN COURS ».
5. Dans tous les états, l'appui sur le bouton éjection entraîne l'éjection de la carte et le retour à « Inactif ».

Réponse : Le diagramme d’états-transitions doit représenter ces états et transitions, avec les affichages correspondants et les actions d’éjection.

Exercice 5 : Retrait d’argent par carte VISA

Un diagramme d’activités permet de modéliser le processus de retrait d’argent avec une carte VISA en intégrant la gestion des erreurs et des contraintes d'éjection.

Les conditions à prendre en compte sont :

• La carte peut être invalide.
• Si elle est valide, le client doit taper son code.
• Après trois essais infructueux, la carte est avalée.
• Le système VISA autorise un montant ou refuse le retrait.
• Une carte non récupérée est avalée.
• Les billets non récupérés sont repris.
• Un ticket est toujours imprimé pendant que les billets sont proposés.

Étapes pour construire le diagramme d’activités :

1. Début puis vérifier la validité de la carte :
   • Si invalide : fin (carte rejetée ou avalée).
   • Si valide : demander la saisie du code.
2. Boucle de saisie du code (3 essais maximum) :
   • Si code correct : demander l'autorisation VISA.
   • Sinon : incrémenter le compteur d'essais.
   • Si 3 essais échoués : avaler la carte puis fin.
3. Autorisation VISA :
   • Si refus : fin.
   • Si accord : proposer des montants.
4. Le client choisit le montant puis impression du ticket (systématique).
5. Délivrer les billets puis attendre la récupération :
   • Si billets non récupérés : reprise des billets.
   • Si carte non récupérée : avaler la carte.
6. Fin.

Réponse : Le diagramme d’activités doit représenter ces flux, conditions, boucles et actions, notamment la gestion des essais, l’autorisation, l’impression du ticket et la récupération ou reprise des billets et cartes.

Exercice 6 : Connexion à un serveur telnet

La connexion d’un client à un serveur telnet se décrit au moyen d’un diagramme d’activités impliquant trois acteurs : client, démon telnet (serveur logiciel) et machine serveur.

Le scénario comprend les étapes suivantes :

• Connexion établie entre client et serveur.
• Le démon demande un mot de passe au client.
• Le client a trois tentatives pour saisir le bon mot de passe.
• Les tentatives infructueuses sont enregistrées dans un fichier sur le serveur.
• Une fois identifié, un terminal s’ouvre.
• L’utilisateur peut saisir des commandes interprétées par le démon et exécutées sur le serveur.
• La commande « exit » déconnecte le client.

Étapes pour le diagramme d’activités :

1. Début puis établir la connexion.
2. Demander le mot de passe avec une boucle de saisie (3 essais maximum) :
   • Si mot de passe correct : ouvrir le terminal.
   • Sinon : enregistrer la tentative échouée puis incrémenter le compteur.
   • Si 3 essais échoués : couper la connexion puis fin.
3. Dans le terminal, boucle de saisie des commandes :
   • Interpréter la commande puis l'exécuter sur le serveur.
   • Si commande = « exit » : déconnecter puis fin.

Réponse : Le diagramme d’activités doit représenter la gestion des tentatives d’identification, l’enregistrement des échecs, l’ouverture du terminal, la saisie et exécution des commandes, et la déconnexion.

Méthode et bonnes pratiques en modélisation UML

La réussite dans la conception de diagrammes dynamiques UML repose sur une application méthodique des principes propres à chaque type de diagramme :

• Pour les diagrammes de séquence et de collaboration, il faut bien identifier les acteurs, objets et messages, respecter l’ordre chronologique des interactions et représenter clairement les flux normaux sans erreurs.
• Pour les diagrammes d’état-transition, il est essentiel de définir précisément les états, les événements déclencheurs des transitions, les actions associées et les conditions de retour aux états initiaux.
• Pour les diagrammes d’activités, la modélisation doit intégrer les décisions, boucles, conditions d’arrêt, actions parallèles ou séquentielles, et représenter clairement les flux alternatifs (succès, échec, exceptions).
• Les erreurs fréquentes à éviter sont : l'omission d’étapes clés, la confusion dans l’ordre des messages, l'absence de gestion des cas d’erreur ou d’exception, et le manque de clarté dans la représentation des transitions ou activités.
• Il est aussi important de respecter les conventions du sujet, notamment les noms des états, messages et conditions, sans les remplacer par des termes non définis dans l’énoncé.

En résumé, la réussite dépend d’une lecture attentive du scénario, d’une traduction fidèle en diagrammes UML, et d’une présentation claire et complète des interactions et comportements du système.