Analyse des relations statiques en modélisation UML

Ce document présente une série d’exercices d’analyse et de modélisation structurelle UML. Il permet d'évaluer la compréhension des relations statiques entre classes, la capacité à identifier et justifier les types de relations UML (généralisation, composition, agrégation, association), ainsi que la modélisation complète par diagrammes de classes et d’objets.

Exercice n°1 : Identification des relations statiques

Pour chaque situation, nous déterminons la relation statique appropriée (généralisation, composition, agrégation ou association) et décrivons la modélisation sous forme de diagramme de classes et d'objets.

a) Frontières entre pays

La relation "frontalière à" lie des instances de la même catégorie sans rapport de subordination ou d'inclusion. Il s'agit d'une association simple binaire réflexive car aucun pays ne fait partie d’un autre.

• Relation : Association simple binaire (réflexive) sur la classe Pays.
• Diagramme d’objets : Instances Tunisie, Algérie et Lybie liées par des liens "frontalière à" entre Tunisie-Algérie et Lybie-Tunisie.
• Diagramme de classes : Classe Pays comportant une association réflexive "frontalière à" avec une multiplicité 0..* de chaque côté.

b) Relation entre une personne et une foule

La foule regroupe des personnes qui conservent leur propre cycle de vie indépendamment de la foule. La relation est une agrégation.

• Relation : Agrégation entre Foule (ensemble) et Personne (élément).
• Diagramme d’objets : Une instance Foule liée à au moins deux instances Personne.
• Diagramme de classes : Classe Foule agrégeant la classe Personne avec une multiplicité 2..* du côté de Personne.

c) Appartenance aux équipes

Une personne peut appartenir à plusieurs équipes et une équipe est composée de plusieurs personnes, sans dépendance d'existence exclusive.

• Relation : Association binaire de type * à *.
• Diagramme d’objets : Plusieurs instances Personne connectées à plusieurs instances Équipe.
• Diagramme de classes : Association entre Personne et Équipe avec une multiplicité * de chaque côté.

d) Structure d'une transaction bancaire

Achat et Vente sont des types particuliers de Transaction bancaire. Il s'agit d'une relation d'héritage.

• Relation : Généralisation entre la superclasse Transaction bancaire et les sous-classes Achat et Vente.
• Diagramme de classes : Classe abstraite ou concrète Transaction bancaire, spécialisée par Achat et Vente.

e) Titularité d'un compte bancaire

Un compte appartient à une personne qui peut être physique ou morale. Personne est une superclasse générale.

• Relation : Association entre Compte bancaire et Personne, combinée à une généralisation de Personne en Personne physique et Personne morale.
• Diagramme de classes : Compte bancaire associé à la classe Personne ; cette dernière est spécialisée par les classes Personne physique et Personne morale.

Exercice n°2 : Qualification des liens et analyse de conformité

1. Type et justification des relations

Analyse des relations entre paires de classes :

• Ordinateur et Système d'Exploitation : Association. Le système d'exploitation et l'ordinateur ont des cycles de vie qui peuvent être distincts (installation, changement d'OS).
• Outil et Marteau : Généralisation. Un marteau est une spécialisation d'un outil.
• Document et Feuille : Composition. La feuille (au sens de page ou composant physique/structurel d'un document) fait partie intégrante du document et sa destruction entraîne généralement celle du composant dans ce contexte.

2. Conformité des diagrammes d'objets

Les représentations visuelles des diagrammes (1), (2) et (3) n'étant pas fournies dans l'extrait source, l'analyse de conformité nécessite de vérifier le respect des multiplicités et des types de liens (alpha1, beta1) par rapport aux associations définies dans le diagramme de classes support.

3. Navigabilité et accès entre B, D et C

La capacité d'accès d'un objet B vers les objets D et C dépend des multiplicités et des orientations des associations portées par le diagramme de classes UML source.

Exercice n°3 : Modélisation d'analyse orientée objet

1. Diagrammes de classes d'analyse

a) Système de réservation et d'activités maritimes :

• Bateau et Cabine : Composition (les cabines n'existent pas sans le bateau qui les contient).
• Cabine et Personne : Association simple "occuper" (multiplicité selon la capacité).
• Personne : Généralisation vers Guide, Animateur et Passager.
• Guide et Passager : Association "expliquer visites".
• Animateur et Passager : Association "animer".
• Opérations : Guide::expliquerVisite(), Animateur::animerAnimation(), Passager::participer().

b) Interface graphique de fenêtres :

• Fenêtre et ses composants : Composition entre Fenêtre et Menu (1..*), Bouton (1..*), et Texte. Association optionnelle (0..1) avec ListeDéroulante.
• Menu et Rubrique : Composition entre Menu et Rubrique (1..*).
• Rubrique : Généralisation vers RubriqueFichier, RubriqueEdition, RubriqueAffichage.
• Fenêtre : Généralisation vers FenêtrePrincipale et FenêtreSecondaire.
• FenêtrePrincipale et FenêtreSecondaire : Association "ouvrir".
• Opérations : Fenêtre::ouvrir(), Fenêtre::fermer().

2. Instanciation par diagrammes d'objets

Pour l'interface graphique, le diagramme d'objets associe une instance :FenêtrePrincipale contenant une instance :Menu (composé de rubriques) à une instance :FenêtreSecondaire créée via l'interaction de l'utilisateur.

Exercice n°4 : Modélisation des emboîtements géométriques

1. Hiérarchie d'héritage

Les classes du domaine sont Figure, Triangle, Carré et Cercle. Figure constitue la superclasse de laquelle héritent Triangle, Carré et Cercle.

2. Diagramme d'objets sans la classe Côté

Les instances de Triangle, Cercle et Carré sont reliées par des associations d'emboîtements : les instances de Triangle contiennent une ou plusieurs figures, les instances de Cercle contiennent exactement une figure, et les instances de Carré ne contiennent aucune sous-figure.

3. Diagramme de classes complet avec compositions

La structure globale s'articule autour des relations suivantes :

• Figure et Côté : Composition entre Figure et Côté. Multiplicité fixée selon la spécialisation (1 pour Cercle, 3 pour Triangle, 4 pour Carré).
• Emboîtements de figures :
  • Composition réflexive entre Triangle et Figure (multiplicité 1..* côté contenu).
  • Composition réflexive entre Cercle et Figure (multiplicité 1 côté contenu).

Exercice n°5 : Conception d'un système de gestion universitaire

Le diagramme d'analyse regroupe la structure administrative, les enseignants, les étudiants et les cours :

• Établissement et Département : Composition (un Établissement regroupe plusieurs Départements).
• Département et Enseignant : Composition (les enseignants sont rattachés à un département). Une association binaire 1 à 1 distingue l'enseignant responsable.
• Enseignant et Matière : Association 1..* à 1 (un enseignant enseigne une seule matière, une matière peut être enseignée par plusieurs enseignants).
• Matière et SalleDeCours : Association * à 1 (plusieurs matières partagent une salle dédiée).
• Étudiant et Matière : Association * à * avec une classe d'association ou un attribut de note.
• Attributs clés :
  • Enseignant : nom, prenom, tel, mail, datePriseFonction, indice.
  • Étudiant : nom, prenom, tel, mail, anneeEntree.
  • SalleDeCours : nombrePlaces.
• Méthodes principales :
  • Matière::calculerMoyenne()
  • Département::calculerMoyenne()
  • Étudiant::calculerMoyenneGenerale(), Étudiant::afficherMatieresNonNotees()
  • Enseignant::imprimerFicheSignaletique(), Étudiant::imprimerFicheSignaletique()

Méthode de résolution des diagrammes UML

La résolution de sujets de modélisation UML s'appuie sur une méthodologie rigoureuse d'analyse du texte :

• Distinction Agrégation / Composition : Vérifier la dépendance d'existence. Si la suppression du composant parent entraîne la suppression des composants enfants, il s'agit d'une composition.
• Détermination des multiplicités : Repérer les quantificateurs dans le texte ("au moins deux" signifie 2..*, "exactement un" signifie 1, "parfois" signifie 0..1).
• Structure d'héritage : Identifier les relations de type "est un" ou "est une sorte de" pour établir des hiérarchies de généralisation.
• Attribution des responsabilités : Placer les méthodes dans les classes possédant les données requises pour le calcul (principe de forte cohésion).