Skip to content

Explication des classes

Jump to bottom
Ben edited this page Jan 13, 2025 · 2 revisions

Les Différentes classes

Diagramme Animaux

Relations UML :

  • Héritage : herbivore et Carnivore héritent de Animal.
  • Association :
    • Animal est composé de Tete, Corps, Membres et est associé à un Habitat.
    • La relation est représentée avec losange noir pour indiquer la composition, sauf pour Habitat (association classique).

Explications et Justifications :

  1. composition
    • utilisée pour les relations entre Animal et ses parties internes (Tete, Corps, Membres).

Une composition signifie que les objets associés ne peuvent exister indépendamment de l’objet principal. Si l’Animal est détruit, ses parties associées (Tete, Corps, Membres) le sont également. Une relation "forte" et nécessaire, comme dans la vraie vie : un animal ne peut pas exister sans une tête ou un corps.

  • Impact sur l'implémentation :
    • Ces objets sont crées dans le constructeur de Animal ou passés directement comme arguments, mais ils dépendent fortement de Animal
    • Une cardinalité obligatoire (1..) impose la validation stricte que ces éléments ne soient jamais None.

  1. Agrégation

    • Non utilisée ici, mais pourrait être pertinente pour représenter des relations où les objets peuvent exister indépendamment.
    • Exemple : Si les Membres devaient indépendants, alors une agrégation (au lieu d'une composition) serait plus adaptée.
    • Différence avec la composition :
      • Dans une agrégation, les objets agrégés peuvent vivre indépendamment de l’objet principal. Par exemple, un Membre pourrait exister sans être attaché à un Animal.
    • Impact sur le code :
      • Au lieu de créer les objets dans le constructeur de Animal, ils peuvent être créés ailleurs et passés comme paramètres sans lien d’exclusivité.

  2. Association simple (flèche) :

    • Utilisée pour la relation entre Animal et Habitat.
    • Pourquoi ?
      • Un Habitat peut exister indépendamment d’un Animal. Plusieurs animaux peuvent partager un même habitat (cardinalité 1..*).
    • Impact sur l’implémentation :
      • Les objets Habitat sont créés séparément et associés à un Animal.
      • On peut avoir un attribut de type référence (self.habitat), mais cela ne nécessite pas de contrôle aussi strict que la composition.

Différence entre Composition et Agrégation au Niveau du Code :

  1. Composition :
    • Les objets dépendants (Tete, Corps, Membres) sont créés ou passés au constructeur de l’objet principal (Animal), et leur existence est subordonnée à celle de cet objet principal.
    • Exemple d’implémentation :
class Animal:
    def __init__(self):
        self.tete = Tete("ronde", "grande")  # Créé directement ici.
  1. Agrégation :
    • Les objets agrégés sont créés en dehors de l’objet principal et lui sont associés. Ils peuvent exister indépendamment de celui-ci.
    • Exemple d’implémentation :
class Animal:
    def __init__(self, tete):
        self.tete = tete  # Référence à un objet existant.

tete_independante = Tete("ronde", "grande")
animal = Animal(tete_independante)

Cardinalité et Impact dans le Code :

  1. Cardinalité Obligatoire (1..1 ou 1..*):
    • Code :
      • Valider dans le constructeur que l’attribut est toujours présent (pas None).
      • Exemple :
if not isinstance(tete, Tete):
    raise ValueError("tete doit être une instance de la classe Tete")
  1. Cardinalité Optionnelle (0..1 ou 0..*):
    • Code :
      • Les attributs peuvent être None si la cardinalité est 0..1.
      • Exemple :
class Animal:
    def __init__(self, membres=None):
        self.membres = membres or []  # Valeur par défaut si None.
    * Dans le cas de listes, vérifier que l’attribut est vide ([]) si aucune instance n’est associée.

Conclusion :

  • La composition est utilisée pour des relations "fortes" et nécessaires, comme Animal et ses parties (tête, corps, membres), car ces éléments ne peuvent exister séparément.
  • L’association est utilisée pour des relations plus "faibles", comme Animal et Habitat, où chaque objet peut exister indépendamment.
  • L’agrégation pourrait être utilisée si certains objets (comme des membres) devaient être indépendants ou partagés.

Diagramme Classe

Relations UML :

  • Héritage : Professeur et Eleve héritent de Personne.
  • Association :
    • Classe est liée par agrégation à Professeur et Eleve. Personne est associée à un Dossier.
    • La relation est représentée avec un losange vide pour indiquer l'agrégation, sauf pour Personne et Dossier (association classique).

Explications et Justifications :

  1. Agrégation
    • Utilisée pour les relations entre Classe et Professeur, Eleve.

Une agrégation signifie que les objets associés peuvent exister indépendamment de l’objet principal. Si la Classe est détruite, ses parties associées (Professeur et Eleve) ne le sont pas. C’est une relation "faible", qui reflète la réalité : une classe peut exister sans élèves (par exemple, la classe reste une structure, même si elle n’a pas encore d’élèves affectés). De même, un élève peut faire partie de plusieurs classes sans que la destruction d'une classe n'affecte l'élève.

-  Impact sur l’implémentation : 
    - Au lieu de créer les objets Professeur et Eleve dans le constructeur de Classe, ils peuvent être créés ailleurs et passés comme paramètres à la Classe. Cela permet de partager un même Professeur entre plusieurs classes et d'affecter un même élève à plusieurs classes sans créer de lien exclusif.
  1. Association simple (flèche) :
    • Utilisée pour la relation entre Personne et Dossier.
    • Pourquoi ?
      • Dans cette situation, j'ai considéré qu'un Dossier peut exister indépendamment d’une Personne. Dans le monde réel, une personne qui quitterait l'école pourrait toujours avoir son dossier enregistré dans celle-ci (par exemple, pour garder une trace administrative ou pour une réinscription future). Le Dossier est lié à la Personne, mais sa gestion n'est pas directement liée à la durée de vie de la Personne.
    • Impact sur l’implémentation :
      • Les objets Dossier sont créés séparément et associés à une Personne par l'intermédiaire du constructeur. La relation entre les deux est une simple association, ce qui signifie qu'un Dossier peut être réutilisé indépendamment d'une Personne.

Différence entre Composition et Agrégation au Niveau du Code :

  1. Composition :

Si j'avais utilise une composition plutot qu'une simple association :

* Dans le cas de la composition, l'objet contenu (par exemple, un objet Dossier) est créé et géré par l'objet principal (Personne). Si l'objet principal est détruit, l'objet contenu est également détruit. La durée de vie de l'objet contenu est directement liée à celle de l'objet composite.
* Exemple dans le code : 

class Personne:
    def __init__(self, dossier: Dossier):
        self.dossier = dossier  # Si Personne est détruite, son Dossier l'est aussi.
  1. Agrégation :
    • Dans l'agrégation, l'objet contenu (par exemple, un Professeur ou un Eleve) peut exister indépendamment de l'objet principal (Classe). La durée de vie de l'objet contenu n'est pas liée à celle de l'objet qui l'agrège. L'objet contenu peut être réutilisé dans différents contextes.
    • Exemple dans le code :
class Classe:
    def __init__(self, professeur: Professeur, nom_classe: str):
        self.professeur = professeur  # Agrégation : Professeur peut exister indépendamment de la Classe.
        self.eleves: List[Eleve] = []  # Agrégation : Élèves peuvent exister indépendamment de la Classe.

Cardinalité et Impact dans le Code :

La cardinalité définit le nombre d'instances d'une classe pouvant être liées à une autre classe dans une relation donnée. Par exemple, dans le cas de la classe Classe :

  • Une Classe peut avoir un seul Professeur et plusieurs Eleves. Cela reflète une cardinalité de 1..1 pour Professeur et 0..* pour Eleve. Le professeur est associé à une seule classe, tandis qu'un élève peut appartenir à plusieurs classes (selon la gestion de l'école).
  • Impact sur le code : La classe Classe contient une seule instance de Professeur et une liste d'instances de Eleve, et cela permet de gérer les associations respectivement de manière un-à-un et un-à-plusieurs. Il n’y a pas de restriction qui empêche de changer le professeur d’une classe ou de déplacer un élève d’une classe à une autre.

Conclusion :

  • L'agrégation est utilisée pour des relations "faibles" et partagées, comme entre Classe et Professeur ou Eleve, car ces objets peuvent exister indépendamment et être partagés entre plusieurs classes ou contextes.
  • L'association est utilisée pour des relations simples, comme entre Personne et Dossier, où chaque objet peut exister séparément mais est lié à l'autre de manière non exclusive.
  • La composition n'est pas utilisée dans ce cas, car il n'y a pas de relations "fortes" nécessitant une gestion exclusive de la durée de vie des objets associés.

Diagramme Email

Relations UML :

  • Composition : AdresseEmail, TexteEmail et FichierJoint sont liés par composition à Email.

Clone this wiki locally