Analyse, Conception Objet Diagrammes de Classes

Transcription

Analyse, Conception Objet Diagrammes de Classes
Diagrammes de classes
SIMMO/ENSM.SE
Diagrammes de classes
Analyse, Conception Objet
SIMMO/ENSM.SE
Sommaire
• Définition
Diagrammes de Classes
• Paquetages
• Classe
• Association
• Aggrégation
Une partie du matériau de ce cours est issue du cours de S.Galland ([email protected])
• Composition
Septembre 2003
• Généralisation
• Relation de dépendance
• Classe abstraite
• Interface
• Classe utilitaire
Sept.2003
1
Diagrammes de classes
SIMMO/ENSM.SE
Sept.2003
Diagrammes de classes
SIMMO/ENSM.SE
Utilisation
Définition
• Lors de l’analyse et de la conception:
• Point central de la modélisation du système pour exprimer
sa structure statique.
– Définitions formelles des objets qui composent le
système à partir des cas d’utilisation et des diagrammes
d’interaction (séquences et collaboration).
• Représentation d’un ensemble de classes, d’interfaces et de
paquetages ainsi que leurs relations.
– Bases conceptuelles pour les diagrammes
d’état-transition, de déploiement, ...
• Une classe décrit un ensemble d’objets (instances de la
classe).
• Lors de l’implantation :
• Une association décrit un ensemble de liens (instances de
l’association).
Sept.2003
Sommaire– 2
– Génération automatique des structures statiques du
système (classes, relations, ...).
Définition– 3
Sept.2003
Utilisation– 4
Diagrammes de classes
SIMMO/ENSM.SE
Diagrammes de classes
Paquetages
Classe
• Définition : description d’un ensemble d’objets partageant les mêmes
attributs, opérations, méthodes, relations et sémantiques.
• Définition : Mécanisme de partitionnement des modèles et de regroupement des
éléments de modélisation.
• Chaque paquetage peut contenir un ensemble de diagrammes et/ou de
paquetages.
• Généralement, en fonction de l’objectif du diagramme, elle est décrite
par : un nom (obligatoire), des attributs, des opérations, des
exceptions, ...
• Chaque élément d’un paquetage possède un nom unique dans ce paquetage.
• Possibilité de définir des relations entre paquetages (dépendances, cf. plus loin).
• Un nom de classe est unique au sein du paquetage
Nom de paquetage::nom de la classe
Pack1
Classe1
1..2
SIMMO/ENSM.SE
Pack1::Classe2
• Rque : les objets sont représentés comme les classes avec leur nom
souligné.
Pack2
*
<<importe>>
Classe1
InnerPack
Sept.2003
Paquetages– 5
Diagrammes de classes
SIMMO/ENSM.SE
Sept.2003
Classe– 6
Diagrammes de classes
Classe (suite)
Stéréotype
• Un stéréotype permet d’étendre les classes déjà existantes en leur
donnant une signification sémantique différente.
• Représentation UML :
Nom de classe
Nom de classe
SIMMO/ENSM.SE
Nom de classe
• Si la classe A est un stéréotype de la classe B, alors A se comporte
comme B tout en ayant une signification sémantique différente.
Attributs
attribut1
attribut2
• Mécanisme proche de la généralisation/spécialisation sauf qu’il permet
le changement de sémantique.
Opérations
op1()
op2()
• Représentation UML :
<<stéréotype>>
Nom de classe
Sept.2003
Classe (suite)– 7
Sept.2003
Classe (suite)– 8
Diagrammes de classes
SIMMO/ENSM.SE
Diagrammes de classes
SIMMO/ENSM.SE
Attribut
Stéréotype (suite)
• Définition : propriété définie par un nom, un type et éventuellement une
valeur initiale.
• Quelques stéréotypes prédéfinis :
énumération: classe définissant un ensemble d’identificateurs
formant le domaine de valeur d’un type.
• Syntaxe UML :
[ visibilité ] nom attribut [ multiplicité ] :
type attribut [ = valeur initiale ]
utilitaire: classe réduite au concept de module et qui ne peut être
instanciée.
– visibilité : cf. plus loin.
acteur: classe modélisant un ensemble de rôles joués par un
acteur.
– nom attribut : identificateur de l’attribut, unique au sein de la
classe.
interface: classe contenant uniquement une description des
opérations visibles.
– multiplicité : l’attribut représente un ensemble de valeurs;
exemple de tableau: Parents[ 1..2 ] : Personne.
exception: classe modélisant un cas particulier de signal : les
exceptions.
Sept.2003
– valeur initiale : valeur prise par l’attribut lors de
l’instanciation de la classe (valeur en concordance avec le type de
l’attribut).
Classe (suite)– 9
Diagrammes de classes
SIMMO/ENSM.SE
Sept.2003
Diagrammes de classes
Attribut : Type
SIMMO/ENSM.SE
Attribut : Type (suite)
• Mutabilité : contrainte quant aux possibilités de modificiation d’un
attribut.
La mutabilité peut être :
• type attribut : ensemble des valeurs pouvant être
prises par l’attribut.
Il peut être :
– {gelé} : attribut non modifiable (ou constante),
– une classe : Rectangle, Cercle, Personne, ...
– {variable} : modifiable à tout moment (mutabilité par défaut),
– un type primitif : Entier, Chaı̂ne de
caractères, Booléen, ...
– {ajoutUniquement} : seul l’ajout est possible (si multiplicité
> 1)
Télévision
– une expression complexe dont la syntaxe n’est pas
précisée par UML : ensemble de n points, ...
Sept.2003
Classe (suite)– 10
on/off : Bouton
couleur : enum{ gris, noir }
marque : Chaîne
télétexte : Booléen = Vrai
chaînes [ 5.. * ] : Canal
type : TypeTV { gelé }
Classe (suite)– 11
Sept.2003
Canal
Bouton
<<énumération>>
TypeTV
16/9
4/3
Classe (suite)– 12
Diagrammes de classes
SIMMO/ENSM.SE
Diagrammes de classes
Attribut : attribut dérivé
Opération
• Définition : spécification du comportement des instances de la classe.
• Parfois des propriétés redondantes sont spécifiées lors de
l’analyse.
• Cinq catégories d’opérations :
– les constructeurs qui créent les objets,
• Les propriétés entièrement dépendantes d’autres propriétés
peuvent être exprimées à l’aide d’attributs dérivés.
– les destructeurs qui détruisent les objets,
• Un attribut dérivé peut être traduit par une opération.
– les sélecteurs (opérations de consultation) qui renvoient tout ou
partie de l’état d’un objet,
Rectangle
Rectangle
Longueur : Entier
Largeur : Entier
/Surface : Entier
Longueur : Entier
Largeur : Entier
{ surface =
Longueur * Largeur }
Surface() : Entier
– les modificateurs qui changent tout ou partie de l’état d’un objet,
– les itérateurs qui visitent l’état d’un objet ou le contenu d’une
structure de données contenant des objets.
renvoie
Longueur * Largeur
Sept.2003
Classe (suite)– 13
Diagrammes de classes
SIMMO/ENSM.SE
Sept.2003
Classe (suite)– 14
Diagrammes de classes
Opération (suite)
SIMMO/ENSM.SE
Opération : arguments
• arguments : description des valeurs nécessaire à l’opération.
• Syntaxe UML :
[ visibilité ] nom opération ( [ arguments ] ) :
type retourné propriétés
• Syntaxe UML :
[ direction ] nom argument : type argument [ =
valeur par défaut ] [ , autres arguments ]
– visibilité : cf. plus loin.
Sept.2003
SIMMO/ENSM.SE
– nom opération : identificateur de l’opération, unique au sein de
la classe.
– valeur par défaut : valeur prise par l’argument si aucune
valeur n’est donnée lors de l’utilisation de cette opération.
– type retourné : type de la valeur retournée par l’opération; si
omis l’opération ne retourne aucune valeur.
– direction : UML définit trois directions pour les arguments
∗ in (par défaut) : paramètre en entrée seule et non modifié par
l’exécution de l’opération,
∗ out : paramètre en sortie seule; l’appelant peut ainsi récupérer
des informations,
∗ inout : paramètre en entrée-sortie; l’argument est passé à
l’opération et modifiable.
Classe (suite)– 15
Sept.2003
Classe (suite)– 16
Diagrammes de classes
SIMMO/ENSM.SE
Diagrammes de classes
SIMMO/ENSM.SE
Opération : propriétés
Opération : implémentation
• UML définit cinq propriétés pour les opérations:
• Spécification d’une pré-condition : condition qui doit être toujours
vraie avant l’exécution de l’opération.
– requête [ = vrai | faux ] : si vrai (par défaut), l’opération
n’altère pas l’état de l’instance.
• Spécifciation d’une post-condition : condition qui est toujours vraie
après l’exécution de l’opération.
– abstrait [ = vrai | faux ] : si vrai (par défaut), indique une
opération non implémentée c-à-d, une opération dont l’implémentation
devra être obligatoirement réalisée par les classes filles.
• Implémentation avec des diagrammes état-transition, des diagrammes
de collaboration, du pseudo-code, ...
– estFeuille [ = vrai | faux ] : si vrai (par défaut), indique
une opération qui ne peut pas être réimplémentée par une classe fille.
− nombre_éléments : Entier = 0
+ retirerSommet() : Booléen
+ nbrElements() : Entier
– concurrence = séquentiel | gardé | concurrent :
précise le mécanisme d’exécution concurrente de l’opération.
Sept.2003
Classe (suite)– 17
Diagrammes de classes
{ <<pré−condition>>
nombre_éléments > 0 }
Pile d’assiettes
– estRacine [ = vrai | faux ] : si vrai (par défaut), indique
qu’une opération est définie pour la première fois dans une hiérarchie de
classes.
SIMMO/ENSM.SE
renvoie
nombre_éléments
Sept.2003
Classe (suite)– 18
Diagrammes de classes
Visibilité des membres
SIMMO/ENSM.SE
Visibilité des membres (suite)
• UML définit trois niveaux de visibilité :
– public : l’élément est visible pour tous les
clients/utilisateurs de la classe, noté par +.
<<visible>>
A
B
+ attr_public : Entier
# attr_protégé : Booléen
− attr_privé : Chaîne
– protégé : l’élément est visible pour les sous-classes
de la classe, noté par #.
+ op_publique()
# op_protégée()
− op_privée()
– privé : l’élément est visible pour la classe seule, noté
par -.
C
Sept.2003
<<visible>>
Classe (suite)– 19
Sept.2003
<<visible>>
<<visible>>
Classe (suite)– 20
Diagrammes de classes
SIMMO/ENSM.SE
Diagrammes de classes
SIMMO/ENSM.SE
Association
Portée des membres
• UML définit deux niveaux de portée :
• Définition : relation entre au moins deux classes qui
entraı̂nent des connexions entre leurs instances.
– portée d’instance (par défaut) : les éléments sont valides pour d’une
seule instance de la classe; les éléments n’ont aucune existance en
dehors de l’instance.
• Représentation UML : trait reliant les deux classes en
relation.
– portée de la classe : les éléments sont toujours valides; ils ne sont
pas attachés à une instance particulière mais à une classe.
• Syntaxe UML : un élément ayant une portée de classe est souligné
+ Parents [ 1..2 ] : Personne
Classe A
Classe B
A
+ ID : Entier
+ nombre_instances : Entier
Sept.2003
Classe (suite)– 21
Diagrammes de classes
SIMMO/ENSM.SE
Sept.2003
Association– 22
Diagrammes de classes
SIMMO/ENSM.SE
Association : arité
Association : arité (suite)
• Les association ont le plus souvent une arité binaire : deux
classes en relation.
Salle
1
Etudiant
• Représentation UML des associations d’arité supérieure
(n-aire) : losange.
2..*
1
Enseignant
Cours
début
fin
• Traduire une association d’arité n-aire en un ensemble
d’associations binaires.
Salle
• Note : la difficulté de trouver un nom différent pour chaque
extrémité d’une association n-aire est souvent le signe
d’une association d’arité inférieure.
Sept.2003
1
Etudiant
Association– 23
Sept.2003
2..*
1
1
<<association ternaire>>
Cours
début
fin
1
1
Enseignant
Association– 24
Diagrammes de classes
SIMMO/ENSM.SE
Diagrammes de classes
SIMMO/ENSM.SE
Association : nommage
Association : rôles des extrémités
• Les associations peuvent être nommées c.-à-d. identifiées
par un texte unique décrivant la sémantique de
l’association.
• Les extrémités des associations peuvent être qualifiées par des rôles.
Travaille pour
Personne
• Un rôle indique comment une classe Source voit une classe
Destination.
Source A
Société
• Note : utiliser une forme verbale active (“travaille pour”) ou
passive (“employé par”).
Société
Société
Association– 25
Diagrammes de classes
SIMMO/ENSM.SE
Association– 26
Diagrammes de classes
SIMMO/ENSM.SE
Association : multiplicité (suite)
• Définition : la multiplicité précise le nombre d’instances pouvant être
liées par une extrémité d’association à une instance pour chaque autre
extrémité d’association.
• Multiplicités définies par UML :
• Sous sa forme générale, elle s’exprime par une suite d’intervalles
disjoints sur l’ensemble des entiers naturels.
• Sous-estimer la multiplicité des associations réduit la flexibilité du
modèle, la sur-estimer conduit à des développements inefficaces.
Sept.2003
1..10
B
Société
Personne
Sept.2003
Association : multiplicité
A
employé
• Note : ne pas utiliser à la fois le nommage d’une association et les rôles
des extrémités de la même association.
Personne
Sept.2003
employeur
Destination B
• Le rôle est un pseudo-attribut de la classe source (utilisé comme un
attribut).
• Si ambiguı̈té, indiquer le sens de lecture avec les signes ou (par défaut lecture de gauche à droite).
Travaille pour
rôle de B
employeur
0..1
0..*
employé
Personne
Association– 27
Sept.2003
1
un et un seul (multipicité par défaut)
0..1
zéro ou un
N
exactement N
M..N
de M à N
*
zéro ou plus, c.-à-d. de 0 à +∞
0..*
zéro ou plus, c.-à-d. de 0 à +∞
1..*
un ou plus, c.-à-d. de 1 à +∞
Association– 28
Diagrammes de classes
SIMMO/ENSM.SE
Diagrammes de classes
SIMMO/ENSM.SE
Association : qualification
Association : contraintes
• Clé d’accés sur l’ensemble des instances que représente l’association.
• Expression de contraints sur les extrémités, entre associations, . . . (cf.
cours OCL).
Plateau
1
Plateau
Personne
Abscisse
Ordonnée
1
0..*
{ordonné}
Compte
Secteur
1
PC portable
1..n
{ou−exclusif}
Batterie
1
Case
Case
Parents d’élèves
*
Classe
{sous−ensemble}
d’école
Personne
*
Délégués
Sept.2003
Association– 29
Diagrammes de classes
SIMMO/ENSM.SE
Sept.2003
Association– 30
Diagrammes de classes
Association : classe-association
SIMMO/ENSM.SE
Association : classe-association (suite)
• Si une association possède des propriétés ou des opérations, il est
possible de la qualifier à l’aide d’une classe-association.
• Lors de la conception, une classe-association peut être
remplacée par une classe intermédiaire.
• Une classe-association possède les mêmes caractéristiques que les
associations et les classes.
Etudiant
réalise
1..*
0..*
Travail
m
A
B
n
note : 0..20
attribut
• Une classe-association qui ne participe pas à d’autres relations avec
d’autres classes peut ne pas porter de nom.
A
Sept.2003
Association– 31
Sept.2003
m
C
attribut
n
B
Association– 32
Diagrammes de classes
SIMMO/ENSM.SE
Diagrammes de classes
SIMMO/ENSM.SE
Composition
Aggrégation
• Définition : forme spéciale d’association exprimant une relation de
composition entre aggrégats (part-whole).
• Cas particulier d’aggrégation. La classe ayant le rôle prédominant est la
classe composite ou classe conteneur.
• Association irréflexive, antisymétrique dans laquelle une des
extrémitiés joue un rôle prédominant, pouvant être récursive.
• La composition implique :
– la durée de vie des composants est la même que celle du composite.
• Permet de modéliser les contraintes d’intégrité et de désigner les
aggrégats comme garant de ces contraintes.
– la multiplicité du côté du composite prend ses valeurs dans 0 ou 1.
• La composition et les attributs sont sémantiquement équivalents.
• A travers une aggrégation, il est possible de représenter :
Composite
– la propagation des valeurs d’attributs d’une classe vers l’autre;
– une action sur une classe qui implique une action sur une autre
classe (ex: copie profonde);
Voiture
0..1
*
Voiture
m : Moteur
Composant
m
1
Moteur
– une subordination des objets d’une classe à ceux d’une autre.
propriétaire
Personne
1..*
0..*
Immeuble
Sept.2003
Aggrégation– 33
Diagrammes de classes
SIMMO/ENSM.SE
Sept.2003
Composition– 34
Diagrammes de classes
SIMMO/ENSM.SE
Généralisation : simple
Généralisation
• La généralisation simple est une relation binaire.
• Définition : relation (irréflexive, antisymmétrique, transitive) entre une
classe plus générale et une classe plus spécifique (signifie “est un” ou
“est une sorte de”). Ce n’est pas une association.
• Représentation UML : flèche triangulaire blanche orientée vers la
classe la plus générale.
• Exemple : un animal est un concept plus général qu’un chat ou un
chien. Inversement un chien est un concept plus spécialisé qu’un
animal. La classe Animal est une généralisation de la classe Chat ou
la classe Chien. La classe Chien est une spécialisation de la classe
Animal.
Animal
Chien
Chat
Cheval
Animal
• L’élément plus spécifique peut contenir des informations qui lui sont
propres, à condition que ces informations et la description des éléments
plus généraux soient totalement cohérentes.
Chien
Chat
Cheval
• Deux types de généralisation : simple ou multiple.
Sept.2003
Généralisation– 35
Sept.2003
Généralisation– 36
Diagrammes de classes
SIMMO/ENSM.SE
Diagrammes de classes
Généralisation : simple (suite)
SIMMO/ENSM.SE
Généralisation : simple (suite)
• La classe la plus générale peut être nommée : “classe
mère”, “classe parent”, “superclasse”, “classe de base”.
• Les sous-classes héritent des attributs, des opérations, des
relations et des contraintes définies dans la classe mère.
• La classe la plus spécialisée peut être nommée : “classe
fille”, “classe enfant”, “sous-classe”, “classe dérivée”.
• Héritage: mécanisme permettant à une classe d’utiliser les
membres de sa classe mère sans avoir à les redéfinir.
• La classe la plus élévée dans la hiérarchie (pas de
généralisation) est souvent nommée “classe racine”.
Animal
# âge : Entier = 0
+ mange()
Chat
+ anniversaire()
Sept.2003
Généralisation– 37
Diagrammes de classes
SIMMO/ENSM.SE
Sept.2003
• Définition : mécanisme permettant à une classe d’avoir
plusieurs classes mères.
Animal
+ mange() : Type_Alimentation
SIMMO/ENSM.SE
Généralisation : multiple
• Définition : mécanisme permettant à une classe fille la spécialisation
d’opérations.
Omnivore
Carnivore
Herbivore
Généralisation– 38
Diagrammes de classes
Polymorphisme
<<énumération>>
Type_Alimentation
{ âge :=
âge + 1; }
• Les superclasses n’ont pas forcément d’ancêtres communs.
renvoie
Omnivore
Véhicule
Lion
Vache
+ mange() : Type_Alimentation
+ mange() : Type_Alimentation
Humain
Tapis
Aérien
Tapis volant
renvoie
Carnivore
renvoie
Herbivore
• Tapis volant hérite des propriétés de Tapis et de
Aérien.
• L’exécution de l’opération mange() déprendra du type réel de l’objet :
Lion::mange() pour un Lion et Animal::mange() pour un Humain.
Sept.2003
Généralisation– 39
Sept.2003
Généralisation– 40
Diagrammes de classes
SIMMO/ENSM.SE
Diagrammes de classes
Relation de dépendance
Relation de dépendance (suite)
• Définition : relation unidirectionnelle indiquant qu’un changement dans la cible
(fournisseur) provoque un changement dans la source (client).
• Stéréotypes prédéfinis dans UML pour les relations de dépendance :
– Liaison : lie
• Relation non structurelle existant entre plusieurs éléments.
– Utilisation : utilise, appelle (une opération source appelle
une autre opération cible), crée (une instance de la classe source crée
une instance de la classe cible), instancie (une opération de
l’élément source crée une instance de l’élément cible), instance
de (l’élémént source est une instance de l’élément cible).
• Représentation UML : une flèche pointillé éventuellement stéréotypée.
• Quatre types de relations de dépendances :
Abstraction: relation entre éléments qui représentent un même concept à
différents niveaux d’abstraction ou selon des points de vue distincts;
– Permission : ami (permet à l’élément source d’ignorer la propriété de
visibilité de l’élément cible),
Liaison: dépendance entre une classe paramètrable (cible) et une classe
paramètrée (source);
– Abstraction : dérive (un élément source est défini ou calculé à
partir d’un élément cible), raffine relation de dépendance entre
deux éléments à des niveaux sémantiques différents, réalise :
l’élément source implémente la spécification désignée par l’élément cible.
Permission: l’élément source a le droit d’accéder à l’espace de nommage de
l’élément cible;
Utilisation: l’élément source requiert la présence d’un élément cible.
Sept.2003
Relation de dépendance– 41
Diagrammes de classes
SIMMO/ENSM.SE
Sept.2003
• On définit une classe abstraite lorsque :
– il est impossible de connaı̂tre l’implantation d’une méthode
(abstractisation d’une opération).
Exemple : l’opération manger() de la classe Animal n’a pas de
sens sémantique propre; il s’agit d’une propriété existant chez tous
les animaux; il est impossible de préciser le comportement de ce
service au niveau de la classe Animal.
• Représentation UML : définition de la classe avec la propriété {abstrait}
ou si une de ses opérations (héritée ou non) possède la propriété {abstrait
= vrai}.
Classe A
{ abstrait }
+ mange() : Type_Alimentation {abstrait}
Omnivore
Carnivore
Herbivore
SIMMO/ENSM.SE
Classe abstraite (suite)
• Définition : classe non instanciable définissant au moins un mécanisme général
instanciable par des classes filles.
Animal
Relation de dépendance (suite)– 42
Diagrammes de classes
Classe abstraite
<<énumération>>
Type_Alimentation
SIMMO/ENSM.SE
– l’instanciation d’une classe n’a aucun sens sémantique ou pratique.
Lion
Vache
Humain
+ mange() : Type_Alimentation
+ mange() : Type_Alimentation
+ mange() : Type_Alimentation
renvoie
Herbivore
renvoie
Omnivore
renvoie
Carnivore
Sept.2003
Classe abstraite– 43
Sept.2003
Classe abstraite (suite)– 44
Diagrammes de classes
SIMMO/ENSM.SE
Diagrammes de classes
SIMMO/ENSM.SE
Interface
Interface (suite)
• Définition : description d’un ensemble d’opérations utilisées pour spécifier un
service offert par une classe.
• Ne contient ni attribut, ni association, ni implémentation des opérations (les
opérations sont abstraites).
<<interface>>
Crédit
Entreprise
• Une classe réalisant une interface doit :
<<utilise>>
<<réalise>>
– soit implémenter les opérations de l’interface,
<<utilise>>
– soit définir les opérations de l’interface comme des opérations abstraites
(implémentables par les classes filles).
Client
• Représentation UML :
<<utilise>>
– classe ayant le stéréotype interface, ou par un cercle pour faire
référence à l’interface utilisée dans la classe,
Banque
Crédit
<<interface>>
Assurance
<<réalise>>
mensualité() : Réel
– flèche d’héritage en pointillés pour la réalisation d’une interface par une
classe,
– flèche de dépendance en pointillés pour l’utilisation.
Sept.2003
Interface– 45
Diagrammes de classes
SIMMO/ENSM.SE
Sept.2003
Interface (suite)– 46
Diagrammes de classes
Classe utilitaire
SIMMO/ENSM.SE
Pour en savoir plus ...
• Définition : définition d’une classe dont tous les membres
ont une portée de classe les attributs et les opérations
deviennent des variables et des procédures globales.
“Modélisation objet avec UML”. Muller, Gaertner. 2000. Éditions Eyrolles (http://www.editionseyrolles.com/).
“Le guide de l’utilisateur UML”. Booch. 2000. Éditions Eyrolles.
• Une classe utilitaire ne peut pas être instanciée.
• En Java, une classe utilitaire correspond à une classe qui
ne contient que des membres statiques.
“UML en action – De l’analyse des besoins à la conception en Java”. Roques. 2000. Éditions
Eyrolles.
• Représentation UML : classe ayant le stéréotype
utilitaire.
“Intégrer UML dans vos projets”. Lopez. 1997. Éditions Eyrolles.
<<utilitaire>>
Math
+ sin(Degré) : Réel
+ cos(Degré) : Réel
Sept.2003
Classe utilitaire– 47
Sept.2003
Pour en savoir plus ...– 48