Accueil
 Sommaire
 1  Objectifs de ce cours de modélisation orientée objet
 2  Généralités sur la modélisation orienté objet et sur UML
 3  Analyse, vues cas d'utilisation et processus
 4  Analyse et conception, aspects statiques de la vue logique
 5  Analyse et conception, aspects dynamiques de la vue logique
 6  Conception, aspects langage et technique
 6.1  Rappel des phases du cycle de développement en V
 6.2  Conception des classes
 6.3  Rappel du diagramme de classes de l'étude de cas Studs
 6.4  Traduction des associations en attributs
 6.4.1  Règles de traduction
 6.5  Traduction des agrégations
 6.6  Traduction des compositions~*
 6.7  Traduction de la classe « Façade » du système
 6.8  Encapsulation: visibilité~/~accessibilité des attributs et des opérations
 6.9  Traduction des attributs dérivés
 6.10  Qualification de certaines associations~*
 6.11  Traduction des diagrammes d'interaction en algorithmes
 6.12  Traduction des diagrammes de machine à états
 6.13  Traduction des relations de généralisation spécialisation
 6.14  Traduction des classes d'association~*
 6.15  Méthodologie: une fiche par classe
 QCM
 7  Conception, vues développement et physique
 8  Conclusion
 9  Bibliographie

 Contacts

W3C validator

Département INF  
 Conception et programmation orientées objet


6.4.1 Règles de traduction
  • Attribut du type référence sur un objet de la classe à l’autre extrémité de l’association
    • Référence notée « @ »
  • Autant d’attributs que de classes auxquelles elle est reliée
    • Association binaire = 1 attribut
    • Association n-aire = n - 1 attributs
  • Association unidirectionnelle = pas d’attribut du côté de la flèche
  • Nom de l’attribut = nom du rôle ou forme nominale du nom de l’association
  • Traduction des multiplicités
    • 1 =⇒ @Classe
    • * =⇒ Collection @Classe
    • 0..N =⇒ Tableau[N] Classe
  • Multiplicité avec tri = Collection ordonnée @Classe

    précédent     suivant 


Chaque association navigable à partir d’une classe donne lieu à l’ajout d’un attribut traduisant la possibilité de traverser l’association depuis cette classe vers la/les classe/s à l’autre/aux autres extrémité/s de l’association. Chacun de ces attributs est une référence vers un objet de la classe associée ; cette référence se note « @ » en UML. Par exemple, la classe Facture de l’exemple ci-dessous reçoit un attribut « fournisseur: @Fournisseur ».

Figures/conception_traduction_association

Chaque classe reçoit autant d’attributs que de classes auxquelles elle est reliée. Par exemple, une classe C ayant 2 associations binaires et une ternaire, reçoit 4 attributs : 1 pour chaque association binaire et 2 pour l’association ternaire. Le nom des attributs est par défaut le nom du rôle, sinon est construit à partir de la forme nominale de l’association ou du nom de la classe à l’autre extrémité de l’association.

Si l’association possède une navigabilité (flèche sur le diagramme de classes indiquant que l’association n’existe que dans un sens), seul le sens de navigation autorisée donne lieu à un attribut.

Les multiplicités sont également à prendre en compte. Dans le même exemple, l’attribut factures est une collection (un ensemble) de références vers des objets de type Facture car la multiplicité est comprise entre O et *. L’attribut est déclaré de la façon suivante : « factures: Collection de @Facture ». Il est possible de préciser que cette collection est triée en ajoutant ordonnée. Si la multiplicité est valorisée à un nombre N donné, utilisez un tableau de références qui se note comme ceci : « factures: Tableau[N] @Facture ».

D. Conan, C. Taconet, C. Bac, Télécom SudParis, CSC 4002, Octobre 2015