Série N°2 – Modélisation structurelle UML

Exercice n°1 - Relations statiques appropriées

Pour chaque énoncé, il convient d'identifier les concepts métiers (classes), leurs instances (objets) et la nature exacte des liens qui les unissent (généralisation, composition, agrégation ou association simple).

Phrase a) La Tunisie est frontalière à l’Algérie. La Lybie est frontalière à la Tunisie.

• Relation statique : Association réflexive (une classe reliée à elle-même).
• Diagramme de classes :
  • Classe : Pays
  • Association : Une association reliant Pays à Pays, avec pour rôle "est frontalière de". La multiplicité est de 0..* de chaque côté (un pays peut avoir plusieurs pays frontaliers, ou aucun s'il s'agit d'une île).
• Diagramme d'objets :
  • Objets : tunisie : Pays, algerie : Pays, lybie : Pays.
  • Liens : Un lien d'association entre tunisie et algerie. Un lien d'association entre lybie et tunisie.

Phrase b) Une personne est dans une foule. Une foule contient plusieurs personnes.

• Relation statique : Agrégation. La foule regroupe des personnes, mais les personnes existent indépendamment de la foule (si la foule se disperse, les personnes continuent d'exister).
• Diagramme de classes :
  • Classes : Foule et Personne.
  • Relation : La classe Foule a un losange vide de son côté, relié par un trait à la classe Personne.
  • Multiplicités : 1 (ou 0..1) du côté de Foule, et 1..* (ou 2..* selon la définition stricte d'une foule) du côté de Personne.
• Diagramme d'objets :
  • Objets : f1 : Foule, p1 : Personne, p2 : Personne.
  • Liens : Des liens d'agrégation partent de f1 vers p1 et p2.

Phrase c) Une personne fait partie de plusieurs équipes. Une équipe contient plusieurs personnes.

• Relation statique : Association simple (ou Agrégation partagée). Le terme "fait partie de" peut justifier une agrégation, mais l'association multiple (plusieurs équipes pour une personne) rend l'association simple tout aussi correcte.
• Diagramme de classes :
  • Classes : Equipe et Personne.
  • Relation : Association "fait partie / contient".
  • Multiplicités : 1..* du côté de Personne (l'équipe a plusieurs personnes) et 1..* du côté d' Equipe (la personne est dans plusieurs équipes).
• Diagramme d'objets :
  • Objets : e1 : Equipe, e2 : Equipe, p1 : Personne.
  • Liens : p1 est relié à la fois à e1 et à e2 par des liens d'association.

Phrase d) Une transaction bancaire est un achat ou une vente.

• Relation statique : Généralisation (Héritage). Le mot "est un" est le marqueur classique de l'héritage.
• Diagramme de classes :
  • Super-classe : Transaction (idéalement abstraite).
  • Sous-classes : Achat et Vente.
  • Relation : Flèches à pointe triangulaire vide partant de Achat et Vente vers Transaction.
• Diagramme d'objets :
  • Objets : achat1 : Achat, vente1 : Vente.
  • Note : On n'instancie pas la classe mère si elle est abstraite, on ne peut créer que des instances des classes filles. Il n'y a pas de lien structurel à dessiner entre ces objets dans ce contexte.

Phrase e) Un compte bancaire peut appartenir à une personne physique ou morale.

• Relation statique : Généralisation (pour les types de personnes) et Association (pour l'appartenance du compte).
• Diagramme de classes :
  • Classes : Titulaire (ou Personne, classe mère), PersonnePhysique (fille), PersonneMorale (fille), et CompteBancaire.
  • Relations : Héritage entre PersonnePhysique/PersonneMorale et la classe mère Titulaire. Association "appartient à" entre CompteBancaire et Titulaire.
  • Multiplicités : 1..* côté CompteBancaire (le titulaire peut avoir plusieurs comptes) et 1 côté Titulaire.
• Diagramme d'objets :
  • Objets : entrepriseX : PersonneMorale, jean : PersonnePhysique, compte1 : CompteBancaire, compte2 : CompteBancaire.
  • Liens : compte1 relié à entrepriseX et compte2 relié à jean.

Exercice n°2 - Lecture de diagrammes de classes

L'énoncé fait référence à deux diagrammes, mais nous ne disposons visuellement que des informations extraites du premier, qui définit une classe Personne avec les rôles associatifs : -enfants 0..*, -père 1, -mère 1, et -conjoint 0..*.

Répondons aux questions de déduction pour une personne donnée :

• Peut-on savoir ses fils ? Non. Le modèle liste les -enfants, mais il n'y a aucun attribut de genre (sexe) ou de sous-classe explicite dans ce premier diagramme pour distinguer les fils des filles.
• Peut-on savoir ses garçons (resp. ses filles) ? Non, pour la même raison que ci-dessus. L'information sur le sexe de l'enfant est manquante.
• Peut-on savoir son père (resp. sa mère) ? Oui. Les rôles -père avec la multiplicité 1 et -mère avec la multiplicité 1 permettent de remonter directement aux parents spécifiques.
• Peut-on savoir son conjoint ? Oui. Le rôle -conjoint est modélisé de manière explicite.

Note relative au 2ème diagramme (mentionné à droite dans votre sujet d'origine) : S'il introduit des sous-classes Homme et Femme héritant de Personne, alors il devient possible de déterminer qui sont les fils et les filles en vérifiant le type des instances reliées par le rôle "enfants".

Diagramme d’objets relatif à la famille

En supposant le modèle standard où un Homme et une Femme héritent de Personne :

• Objets instanciés :
  • ali : Homme (ou ali : Personne si l'héritage n'est pas utilisé), avec nom="...", prénom="Ali"
  • emna : Femme, avec nom="...", prénom="Emna"
  • houda : Femme, avec nom="...", prénom="Houda"
  • maher : Homme, avec nom="...", prénom="Maher"
• Liens entre les objets :
  • Lien "conjoint" bidirectionnel entre ali et emna.
  • Lien "père" partant de houda vers ali et de maher vers ali.
  • Lien "mère" partant de houda vers emna et de maher vers emna.
  • Liens "enfants" partant de ali vers houda et maher, et de emna vers houda et maher.

Exercice n° 3 - Modélisation complexe d'analyse

Question 3.1.a - Le Bateau de croisière

• Classes pertinentes : Bateau, Cabine, Personne (super-classe abstraite), Guide, Animateur, Passager, Visite, Animation.
• Relations et Argumentations :
  • Composition entre Bateau et Cabine : "Un bateau contient des cabines". Physiquement, la cabine n'existe pas sans le bateau.
  • Association entre Cabine et Personne : "occupées par des personnes". Multiplicités : 1..* (Personnes) occupent 1 (Cabine).
  • Généralisation : "Les personnes sont ou bien des guides, ou bien...". Guide, Animateur, et Passager héritent de la classe mère Personne.
  • Association entre Guide et Visite : "expliquent des visites".
  • Association entre Animateur et Animation : "animent des animations".
  • Association entre Passager et Visite / Animation : Le passager participe aux activités.

Question 3.1.b - Le logiciel et ses fenêtres

• Classes pertinentes : Fenetre (super-classe abstraite), Menu, Bouton, Texte, ListeDeroulante, Rubrique (super-classe abstraite), RubriqueFichier, RubriqueEdition, RubriqueAffichage, FenetrePrincipale, FenetreSecondaire.
• Relations et Argumentations :
  • Composition Fenetre *-- Menu, Fenetre *-- Bouton, Fenetre *-- Texte : "Une fenêtre est toujours composée d’un...". Si on détruit la fenêtre, ses éléments d'interface disparaissent.
  • Agrégation (ou Composition optionnelle) Fenetre o-- 0..1 ListeDeroulante : "contient parfois".
  • Composition Menu *-- Rubrique : "Un menu contient plusieurs rubriques".
  • Généralisation : RubriqueFichier, RubriqueEdition, RubriqueAffichage héritent de Rubrique ("différents types de rubriques").
  • Généralisation : FenetrePrincipale et FenetreSecondaire héritent de Fenetre.
  • Association dirigée de FenetrePrincipale vers FenetreSecondaire : "ouvrir une fenêtre secondaire à partir de la fenêtre principale".
• Opérations : La classe abstraite Fenetre doit posséder une méthode fermer(), qui sera héritée par toutes les fenêtres pour satisfaire la contrainte "il doit être possible de fermer toutes les fenêtres".

Question 3.2 - Diagrammes d'objets

Pour l'énoncé (a) - Le bateau :

• Objet bat1 : Bateau
• Objets cab1 : Cabine, cab2 : Cabine (liés par composition à bat1).
• Objet passager1 : Passager (lié à cab1 par le rôle "occupe").
• Objet guide1 : Guide (lié à cab2 par le rôle "occupe").
• Objet visiteRome : Visite. Liens d'association depuis guide1 ("explique") et depuis passager1 ("participe").

Pour l'énoncé (b) - Les fenêtres :

• Objet fenPrin : FenetrePrincipale.
• Objets menu1 : Menu, btn1 : Bouton, txt1 : Texte (liés par composition à fenPrin).
• Objets rubF : RubriqueFichier, rubE : RubriqueEdition (liés par composition à menu1).
• Objet fenSec : FenetreSecondaire. Un lien part de fenPrin vers fenSec (représentant l'ouverture). fenSec possèdera ses propres objets Menu, Bouton par composition.

Exercice n°4 - Modélisation d'une expression mathématique

Soit l’expression : (X + Y ÷ 2) ÷ (X ÷ 3 + Y)

Cette problématique fait appel au patron de conception Composite, classique pour la représentation des arbres syntaxiques.

Identification des classes pertinentes

• Expression : classe mère abstraite représentant tout élément évaluable.
• Binaire : classe mère abstraite pour les opérations à deux opérandes (hérite de Expression).
• Addition et Division : sous-classes de Binaire.
• Variable et Constante : sous-classes de Expression (feuilles de l'arbre).

Diagramme de classes

• Généralisation : Binaire, Variable et Constante héritent de Expression.
• Généralisation : Addition et Division héritent de Binaire.
• Agrégation / Association : La classe Binaire possède deux associations dirigées vers Expression nommées respectivement operandeGauche et operandeDroite (multiplicité 1 de chaque côté).

Diagramme d’objets

Le diagramme d'objets prend la forme d'un arbre reflétant l'ordre de priorité des opérations (les parenthèses forcent la structure) :

• Nœud Racine : div_principale : Division
  • Lien operandeGauche vers : add_gauche : Addition
    • Lien operandeGauche vers : varX1 : Variable (nom="X")
    • Lien operandeDroite vers : div_interne1 : Division
      • Lien operandeGauche vers : varY1 : Variable (nom="Y")
      • Lien operandeDroite vers : const2 : Constante (valeur=2)

Lien operandeDroite vers : add_droite : Addition

• Lien operandeGauche vers : div_interne2 : Division
  • Lien operandeGauche vers : varX2 : Variable (nom="X")
  • Lien operandeDroite vers : const3 : Constante (valeur=3)
• Lien operandeDroite vers : varY2 : Variable (nom="Y")

(Note : Dans de nombreux modèles d'arbres, varX1 et varX2 peuvent pointer vers la même instance d'un objet si l'on applique le patron Poids-Mouche / Flyweight, mais l'instanciation de deux objets distincts est la norme pour un diagramme d'objets basique).

Exercice n°5 - Analyse du SI de l'entreprise

Il s'agit d'extraire les entités et leurs attributs directement du texte fourni.

• Classe DirectionRegionale
  • Attributs : code, libellé
  • Relation : Pilote des agences locales (Association dirigée). Multiplicité : 1 (Direction) → 1..* (Agences).
• Classe AgenceLocale
  • Attributs : code, intitulé, date_creation, date_fermeture
  • Relation : A pour personnel des personnes (Association). Multiplicité : 1 (Agence) → 1..* (Personnes).
• Classe Personne
  • Attributs : numero, qualite, nom, prenom, date_naissance, date_previsionnelle_arrivee, date_arrivee, date_depart.

Le diagramme de classes final est strictement linéaire (une hiérarchie organisationnelle) : DirectionRegionale (1) --- pilote ---> (1..*) AgenceLocale (1) --- rattache ---> (1..*) Personne.

Méthode

Pour aborder une épreuve de modélisation structurelle UML :

1. L'analyse lexicale : Repérez les substantifs (noms communs) dans l'énoncé : ce sont vos classes candidates. Repérez les verbes (est, contient, possède, dirige) : ce sont vos associations.
2. Identification des relations :
   • "Est un", "est une sorte de" → Généralisation (héritage).
   • "Possède", "Fait partie de", où l'élément contenu peut survivre sans le conteneur → Agrégation.
   • "Est composé de", "Est détruit si le parent l'est" → Composition.
3. Abstraction : Ne modélisez que ce que l'énoncé vous donne. N'inventez pas d'attributs qui semblent "logiques" (comme l'adresse d'une personne) s'ils ne sont pas explicitement demandés ou déductibles du texte.
4. Instanciation (Diagramme d'objets) : C'est la preuve que votre modèle fonctionne. Vérifiez que la création d'un objet respecte les règles (on ne peut pas instancier une classe abstraite, on doit respecter les multiplicités de la classe).