Correction du devoir de Cours sur UML

Exercice 1 - Le concept

Question 1a - Définition et utilité d'un modèle

Un modèle est une représentation abstraite d'un système. Son rôle principal est de faciliter l'étude de ce système et d'améliorer la communication entre les différents intervenants d'un projet. La notion d'abstraction est centrale ici : il s'agit de ne retenir que les caractéristiques essentielles d'une entité selon le point de vue d'un observateur donné, en masquant les détails inutiles.

Pour illustrer ce concept en dehors de l'informatique (comme demandé), la correction propose l'exemple du modèle économique. En s'appuyant sur des hypothèses macro-économiques (telles que l'évolution du taux de chômage ou le taux de croissance), les économistes créent un modèle abstrait de la réalité. L'avantage majeur est de pouvoir réaliser des simulations, par exemple anticiper l'évolution des cours boursiers, sans avoir à manipuler le système réel.

Question 1b - Vue statique vs vue dynamique

La distinction repose sur la notion de temps :

• Vue statique : Elle représente la structure du modèle à un instant donné, sans tenir compte de son évolution dans le temps (ex: diagramme de classes).
• Vue dynamique : Elle représente à l'inverse les changements, les interactions et les comportements qui interviennent au cours du temps (ex: diagramme de séquence).

Exercice 2 - Les cas d'utilisation

Question 2a - Objectif du diagramme de cas d'utilisation

L'objectif de ce diagramme est de modéliser l'expression du comportement du système (ses actions et réactions) en se plaçant strictement du point de vue de l'utilisateur.

Question 2b - Intérêts du diagramme

Ce diagramme présente plusieurs avantages cruciaux pour le cycle de vie du projet :

• Il permet de délimiter clairement les frontières du système.
• Il constitue un moyen standardisé d'exprimer les besoins du système.
• Il est compréhensible et utilisé par les utilisateurs finaux pour formuler leurs attentes.
• Il permet d'impliquer ces mêmes utilisateurs dès les tout premiers stades du développement.
• Il sert de base solide pour concevoir les futurs tests fonctionnels.

Question 2c - Exemple de diagramme avec include, extend et commentaire

Note : Le schéma visuel est absent du document source scanné. Il est donc impossible de reproduire le diagramme exact attendu. Toutefois, la correction indique que le diagramme devait comporter un commentaire (note UML) rattaché à une authentification, contenant le texte exact suivant : "Une authentification permet d'être sûr du client distant". Un diagramme correct aurait dû montrer un cas d'utilisation de base, une relation <<include>> (comportement obligatoire), une relation <<extend>> (comportement optionnel) et la note explicative associée.

Exercice 3 - Identification d'un diagramme

Question 3 - Nom du diagramme et explication

La correction signale ici un "piège du devoir". Bien que le diagramme (absent du scan mais décrit dans le texte) montre une collaboration, ce n'est pas un diagramme de collaboration au sens UML classique. Il s'agit en réalité de la modélisation d'une collaboration au sein d'un diagramme de classes. Ce formalisme permet de représenter quelles classes travaillent ensemble pour réaliser un cas d'utilisation spécifique. Dans le cas de l'exercice, il illustre les 3 classes qui participent activement au cas d'utilisation « vente de véhicule ».

Exercice 4 - Diagramme de classe

Note : Les questions 4a à 4e demandaient la construction progressive d'un grand diagramme de classes. Le document source rassemble la correction sous la forme d'un schéma final que nous restituons ici sous forme textuelle.

Question 4a à 4e - Construction et enrichissement du diagramme de classes

Le système modélise la gestion d'un hôtel et est découpé en trois packages distincts (répondant à la question 4e) :

1. Package "Gestionnaire"

• Classe Hotel
  • Attributs : nom (String, public), adresse (String, public), motPasseGerant (String, privé).
  • Méthodes : reserve(int numCh) (booléen, protégé), getIdentifiant() (void, public), paye() (void, public).
• Relations de l'Hôtel :
  • L'hôtel est relié à une personne jouant le rôle de gerant (multiplicité 1).
  • L'hôtel est relié à des personnes jouant le rôle de clients (multiplicité *).

2. Package "Clients"

• Classe Personne
  • Attributs (protégés) : age (int), nom (String), prenom (String).
  • Méthode : vieillit() (void, public).
• Contrainte (Question 4d) : Une contrainte {ou-exclu} (XOR) est placée entre les associations reliant Personne à Hotel. Une instance de Personne est soit un gerant (1), soit un client (0..*), mais ne peut pas être les deux simultanément.

3. Package "Materiel"

• Classe Chambre (Reliée à Hotel, un hôtel possède 0..* chambres et une chambre contient 0..1 nomOccupant de type Personne).
  • Attributs (protégés) : etage (int), prix (int).
  • Méthodes (publiques) : reserve(string nom): void, estVide(): bool.
• Héritage (Question 4b) : Les classes Single et Duo héritent de Chambre.
• Classe Lit : Les classes Baldaquin et Futon héritent de Lit.
• Agrégation et Composition (Question 4c) :
  • Toutes les chambres ont une relation (de multiplicité 1 à 1..*) avec la classe Lit.
  • Les chambres Single ont une relation (multiplicité 1 à 0..1) avec la classe Television.
  • Les chambres Duo ont une relation forte (multiplicité 1 à 1) avec SalleBain. (Note : Le choix entre agrégation - lien faible - et composition - lien fort de cycle de vie - devait être argumenté selon votre conception du système, par exemple une salle de bain est détruite si la chambre Duo l'est (composition), tandis qu'une télévision peut être déplacée (agrégation)).

Exercice 5 - Diagramme d’objet

Question 5a - Représentation d'une situation spécifique

L'énoncé demande de représenter l'instance de l'hôtel "matignon" avec son gérant et un client. Les objets à modéliser sont les suivants :

• Objet Hôtel : matignon : Hotel (L'hôtel possède 50 instances de Chambre, bien qu'une seule soit pertinente pour le lien).
• Objet Gérant : gerant : Personne (avec l'attribut nom = Formul Alain). Cet objet est lié à matignon via l'association gerant.
• Objet Client : client : Personne (avec l'attribut nom = Lelore). Cet objet est lié à matignon via l'association clients. Il est également lié à l'une des instances anonymes : Chambre de l'hôtel.

Exercice 6 - Diagramme de séquence

Question 6a - Exemple avec notions de base

Note : Le schéma est absent du document source. Il est impossible de fournir l'exemple visuel attendu illustrant la création/suppression d'objet, les lignes de vie et les bandes d'activation.

Question 6b - Exemple de branchement conditionnel (Retrait bancaire)

Le diagramme modélise l'interaction entre deux acteurs/objets : un Distributeur et une Banque. La séquence logique est la suivante :

1. Le Distributeur reçoit insereCarte().
2. Le Distributeur reçoit saisiCode().
3. Branchement conditionnel : Un bloc de condition [Si code bon] est évalué.
4. Si la condition est vraie, la séquence se poursuit avec saisiMontant().
5. Le Distributeur envoie le message retrait() à la Banque.
6. En retour, le Distributeur reçoit/exécute delivreArgent().
7. Le Distributeur exécute ejectCarte().

Exercice 7 - Diagramme de collaboration

Question 7a - Explication des messages

Le document détaille la sémantique de plusieurs types de messages UML :

• [heure = midi] 1 : manger()
  • Explication : La présence de crochets indique une condition (garde). Le message manger() n'est envoyé que si la condition "il est midi" est vraie.
• 1 / *|| 2.1 : fermer()
  • Explication : Le message fermer() porte le numéro de séquence 2.1, il n'est donc envoyé qu'une fois le message 1 terminé. L'astérisque * indique qu'il est envoyé un nombre inconnu de fois (itération). Le symbole || indique que l'envoi se fait en parallèle (en même temps) sur tous les récepteurs.
• 1.3,2.1 / [t < 10s] 2.5 : age := demanderAge(nom,prenom)
  • Explication : Le message 2.5 possède des prérequis multiples (1.3, 2.1) : il n'est envoyé qu'une fois les messages 1.3 ET 2.1 terminés. Il est également soumis à la condition t < 10s. Il correspond à l'appel de la fonction demanderAge (qui prend en paramètres nom et prenom) dont la valeur de retour est stockée dans la variable age.
• 1.3 / [disk full] 1.7.a * : deleteTempFiles() et 1.3 / [disk full] 1.7.b : reduceSwapFile(20%)
  • Explication : Les suffixes .a et .b indiquent que ces deux messages sont envoyés en même temps (en parallèle). Cet envoi groupé ne se déclenche qu'après la fin du message 1.3 et uniquement si la condition disk full est vérifiée.

Question 7b - Explication du schéma de détresse

L'objet pa87 (qui se trouve dans un état particulier, indiqué par [etat=detresse]) envoie un message répété (itération due à l'astérisque) un nombre inconnu de fois vers un objet tour de contrôle. Ce message est synchrone (modélisé par une flèche pleine en UML), ce qui signifie que l'émetteur attend une réponse et se synchronise avec le récepteur (par exemple via un protocole d'acquittement : "appel tour de contrôle", attente de réponse, "bien reçu").

Exercice 8 - Diagramme d’états transitions

Question 8a - Création d'un système à 3 états

Note : Le schéma attendu par la correction est manquant dans le document source. Il est donc impossible de vérifier l'exemple précis qui était attendu.

Question 8b - Mots-clés de déclenchement d'action

Dans un état, les actions peuvent être déclenchées à différents moments. Les mots-clés UML officiels sont :

• entry / action : l'action est exécutée au moment exact de l'entrée dans l'état.
• exit / action : l'action est exécutée au moment exact de la sortie de l'état.
• on événement / action : l'action est exécutée de manière ponctuelle à chaque fois que l'événement spécifié survient pendant que le système est dans cet état.
• do / action : représente une action récurrente, continue ou significative qui s'exécute tant que le système reste dans l'état.

Question 8c - États simultanés

Pour représenter qu'un objet se trouve dans deux états en même temps, UML utilise les régions orthogonales (des sous-états concurrents séparés par des lignes pointillées). Note : Le diagramme n'est pas fourni. Selon le texte, en cliquant sur Firefox, le logiciel passe dans l'état global "marche", qui contient lui-même deux sous-états parallèles exécutés simultanément : "écoute le réseau" ET "affiche page accueil".

Exercice 9 - Diagramme de composant

Question 9 - Utilité et explication du schéma

Le diagramme de composants permet de décrire l'architecture physique et statique d'une application en termes de modules logiciels (fichiers sources, bibliothèques, exécutables, etc.). Il montre comment les modèles logiques sont mis en œuvre physiquement dans l'environnement de développement.

Dans l'exemple fourni par la correction, la hiérarchie des dépendances est la suivante : Pour générer l'exécutable final bancDeMesuresTask, 3 objets sont nécessaires. L'un d'eux, BancDeMesures.obj, est généré à partir du fichier source BancDeMesures.cpp. Ce fichier source dépend à son tour de l'inclusion de 3 fichiers d'en-tête (headers) : BancDeMesures.h, Bobine.h et Multimetre.h.

Exercice 10 - Diagramme de déploiement

Question 10 - Utilité et explication du schéma

Les diagrammes de déploiement montrent la disposition physique des matériels qui composent le système, ainsi que la manière dont les composants logiciels sont répartis et installés sur ces matériels. Dans ce formalisme :

• Les ressources matérielles (serveurs, routeurs, postes clients) sont représentées sous forme de nœuds (des cubes en 3D).
• Ce diagramme peut représenter soit des classes de nœuds (des catégories de matériel génériques), soit des instances de nœuds (des machines physiques précises et identifiées).

Méthode

Pour réussir ce type d'épreuve sur la modélisation UML, voici quelques principes directeurs à garder en tête :

1. Connaître la sémantique exacte des mots-clés : UML est un langage normé. Ne confondez pas les concepts proches (comme <<include>> qui est inconditionnel et <<extend>> qui est conditionnel, ou encore l'agrégation et la composition).
2. Savoir lire un énoncé : Les questions comme la 4 (diagramme de classe) sont souvent des exercices de traduction littérale. Une phrase comme "Les chambres Single ont une ou plusieurs Télévision" se traduit immédiatement par une relation avec une multiplicité 1..* côté télévision. Ne surinterprétez pas les besoins.
3. Attention aux pièges sémantiques : Comme le souligne la question 3, identifier un diagramme ne se fait pas uniquement à son aspect visuel global, mais en analysant les formalismes utilisés. Une collaboration peut être montrée de manière statique via un diagramme de classes enrichi de rôles.
4. Justifier les choix d'architecture : En modélisation orientée objet, plusieurs conceptions peuvent être valides (agrégation vs composition pour une salle de bain, par exemple). C'est votre justification qui valide le choix technique.
5. Ne pas négliger la syntaxe textuelle : Les messages de collaboration (ex: 1.3,2.1 / [t < 10s] 2.5 : ...) obéissent à une grammaire très stricte : prédécesseurs / [condition] séquence : action. Savoir la lire de gauche à droite permet de déduire le comportement sans ambiguïté.