 |
|
|
| |
| TUTORIEL ALGO/METHODES |
|
|
|
| Les relations entre classes et leurs représentations UML |
| Les caractéristiques des relations Objet les plus utilisées au sein du langage de modélisation standard.
(20/06/2005) |
  |
Dans le cadre de la programmation
Objet, chaque classe doit être responsable de tâches
précises, laissant à d'autres classes le soin de prendre en
charge d'autres tâches. La combinaison de tous ces objets donne
un programme (normalement) efficacement compartimenté et plus
facile à gérer.
Chaque objet n'agit cependant pas seul dans son coin : tous
sont liés à au moins un autre, que ce soit pour recevoir
un ordre de sa part, pour faire parvenir un résultat, ou pour
travailler conjointement avec un autre objet spécialisé. Les
possibilités sont variées et ont été énumérées au sein de la
spécification UML. La plupart des langages Objet prennent en
compte ces relations entre classes, et offrent les mécanismes
idoines de transfert de message.
Cette communication interclasse est effectivement primordiale
: la manière dont les messages sont échangés entre les objets
est un aspect important de la POO. Elles définissent le fonctionnement
du programme : une application Objet est définie en tant qu'ensemble
d'objets reliés par des relations, qui précisent les comportements
des objets les uns par rapport aux autres. Ces relations mettent
en avant une méthode de programmation basée sur le comportement
plutôt que sur les données brutes.
Cinq types
de relation interclasse sont couramment utilisés (il en existe
d'autres) :
- héritage
- dépendance
- agrégation
- composition
- association
Chacune répond à contexte d'utilisation, et offre des avantages
parfois subtils mais réels.
Heritage
Elle présente une classe spécifique comme descendante d'une
classe plus générique. Cette classe spécifique propose des méthodes
dont la classe générique ne dispose pas, tout en conservant
la plupart des méthodes de cette classe "parente".
En UML, une dépendance est représentée par une ligne en tirets,
terminée par une flèche évidée.
Dépendance
Cette relation est simple à comprendre : elle présente l'utilisation
que fait une classe d'une autre. Une classe dépend d'une autre
si ses méthodes manipulent l'objet de cette classe. Par exemple,
une classe Réservation ne pourrait exister que si la classe
Compte indique les coordonnées de la personne...
En UML, une dépendance est représentée par une ligne en tirets,
terminée par une simple flèche.
Agrégation
Une relation d'agrégation indique un principe de subordination
entre l'agrégat (classe qui regroupe les classes agrégées) et
les agrégées. Concrètement, elle indique une "possession" :
l'agrégat peut contenir plusieurs objets d'un type. Par exemple,
une classe Réservation peut contenir un ou plusieurs objets
de type Place de Cinéma.
En UML, une agrégation est représentée par une ligne entre deux
classes, terminée par un losange vide ("diamant") du côté de
l'agrégat.
Composition
Aussi appelée "agrégation forte" ou "agrégation par valeur",
il s'agit en fait d'une agrégation à laquelle on impose des
contraintes internes : un seul objet peut faire partie d'un
composite (l'agrégat de la composition), et celui-ci doit gérer
toutes ses parties. En clair, les composants sont totalement
dépendants du composite.
En UML, la composition est représentée de la même manière que
l'agrégation, mais le diamant est plein.
 |
Forum |
|
|
Réagissez
dans les forums
de JDN Développeurs
|
Association
C'est la relation la plus simple entre deux classes. Elle existe
à partir du moment où l'une des deux classes sert de type à
un attribut de l'autre, et que cet autre envoi des messages
à la première (condition nécessaire pour une association). Simplement,
une association indique que deux classes communiquent entre
elles (dans un sens ou dans les deux sens).
En UML, une association est représentée par une ligne entre
deux classes, possiblement accompagnée d'une flèche si l'association
n'est pas bidirectionnelle. |
|
|
|
|
|
|
|
| Quand achetez-vous le plus en ligne ? |
|
|
|
|
|
|
|
|
| |
|
