Diagramme de classes

1 Introduction

Le diagramme de classes est considéré comme le plus important de la modé-

lisation orientée objet, il est le seul obligatoire lors d’une telle modélisation.
Le diagramme de classes montre la structure interne du système.
Il permet de fournir une représentation abstraite des objets du système qui
vont interagir ensemble pour réaliser les cas d’utilisation. Il est important de
noter qu’un même objet peut très bien intervenir dans la réalisation de plu-
sieurs cas d’utilisation.

1
Il s’agit d’une vue statique car on ne tient pas compte du facteur temporel
dans le comportement du système.
Il permet de modéliser les classes du système et leurs relations indépendam-
ment du langage de programmation.
Les principaux éléments de cette vue statique sont les classes et leurs rela-
tions : association, généralisation et plusieurs types de dépendances, telles
que la réalisation et l’utilisation.

2
2 Les classes
2.1 Notion de classe et d’instance de classe
Une instance est une concrétisation d’un concept abstrait.
Par exemple :
• la 404 bâchée devant la maison est une instance du concept abstrait
voiture;
• le mariage qui lie Ali et Stéphanie est une instance du concept abstrait
Mariage
Une classe est un concept abstrait représentant des éléments variés comme :
• des éléments concrets (ex : des avions),
• des éléments abstraits ( ex : des commandes de marchandises ou ser-
vices),

3
 • des composants d’une application (ex : les boutons des boîtes de dia-
logue),
• des structures informatiques (ex : des tables de hachage),
• des éléments comportementaux (ex : des tâches), etc.

Tout système orienté objet est organisé autour des classes.

Une classe est la description formelle d’un ensemble d’objets ayant une sé-
mantique et des caractéristiques communes.
Un objet est une instance d’une classe. C’est une entité discrète dotée d’une
identité, d’un état et d’un comportement que l’on peut invoquer.
Les objets sont des éléments individuels d’un système en cours d’exécution.

4
2.2 Caractéristiques d’une classe
Une classe définit un jeu d’objets dotés de caractéristiques communes.
Les caractéristiques d’un objet permettent de spécifier son état et son com-
portement.
État d’un objet :
Ce sont les attributs et les terminaisons d’associations, réunis sous le terme
de propriétés structurelles, qui décrivent l’état d’un objet.
La terminaison de l’association (du côté de la classe cible) est généralement
une propriété de la classe de base.
Les propriétés décrites par les attributs prennent des valeurs lorsque la classe
est instanciée.
L’instance d’une association est appelée un lien.

5
Comportement d’un objet :
Les opérations décrivent les éléments individuels d’un comportement que l’on
peut invoquer. Ce sont des fonctions qui peuvent prendre des valeurs en en-
trée et modifier les attributs ou produire des résultats.
Les attributs, les terminaisons d’association et les méthodes constituent donc
les caractéristiques d’une classe (et de ses instances).
2.3 Représentation graphique

6
Elle est représentée par un classeur composé de 3 compartiments :
• Le premier indique le nom de la classe
• le deuxième ses attributs
• le troisième ses opérations

7
2.4 Encapsulation, visibilité, interface
L’encapsulation est un mécanisme consistant à rassembler les données et les
méthodes au sein d’une structure tout en cachant l’implémentation de l’objet,
c’est-à-dire en empêchant l’accès aux données par un autre moyen que les
services proposés.
Les services accessibles (offerts) aux utilisateurs de l’objet définissent l’inter-
face de l’objet.
L’encapsulation permet donc de garantir l’intégrité des données contenues
dans l’objet.
Il existe quatre visibilités prédéfinies.
Public ou + : tout élément qui peut voir le conteneur peut également voir
l’élément indiqué.

8
Protected ou # : seul un élément situé dans le conteneur ou un de ses des-
cendants peut voir l’élément indiqué.
Private ou - : seul un élément situé dans le conteneur peut voir l’élément.
Package ou ~ ou rien : seul un élément déclaré dans le même paquetage peut
voir l’élément.
Dans une classe, le marqueur de visibilité se situe au niveau de chacune de
ses caractéristiques.

9
2.5 Nom d’une classe
Le nom de la classe doit évoquer le concept décrit par la classe. Il commence
par une majuscule. On peut ajouter des informations subsidiaires comme le
nom de l’auteur de la modélisation, la date, etc. Pour indiquer qu’une classe
est abstraite, il faut ajouter le mot-clef abstract.

2.5.1 Syntaxe de base

La syntaxe de base de la déclaration d’un nom d’une classe est la suivante :
[ <Nom du paquetage 1>: : . . . : :<Nom du paquetage N> ]
<Nom de la classe> [ { [abstract], [<auteur>], [<date>] , ... } ]

10
2.5.2 Les stéréotypes
Un stéréotype permet d'étendre les classes déjà existantes en leur donnant
une signification sémantique différente. C'est à dire, que si A a le stéréotype
de B alors A se comporte comme B tout en ayant une signification sémantique
différente.
C'est une notion proche de la généralisation sans qu'il permet le changement
sémantique.
Certains stéréotypes sont prédéfinis :
◦ <<enumeration>> : classe définissant un ensemble d'identificateurs for-
mant le domaine de valeur d'un type
◦ <<interface>> : une classe contenant uniquement une description des opé-
rations visibles

11
◦ <<exception>> : une classe modélisant un cas particulier d'un signal dit ex-
ception
◦ <<utilitaire>> : une classe modélisant un ensemble de variables et d’opé-
rations globales.
Représentation graphique:

12
2.6 Les attributs
2.6.1 Attributs d’Instances
Les attributs représentent les données encapsulées dans les objets de la
classe. Chacune de ces informations est définie selon la syntaxe suivante :
<visibilité> [/] <nom_attribut> : <type> [ '['<multiplicité>']' [{<contrainte>}] ]
[ = <valeur_par_défaut> ]
• <nom_attribut> : le nom de l’attribut doit être unique dans la classe
• <type> : peut être un nom de classe ou un type de donné prédéfini.
• <multiplicité> : précise le nombre de valeurs que l’attribut peut contenir.
NB. Lorsque la multiplicité est > 1 est précisée, il est possible d’ajouter une
contrainte ({<contrainte>}) pour préciser si les valeurs sont ordonnées ({or-
dered}) ou pas ({list}).

13
 2.6.2 Attributs de classe
Par défaut, chaque instance d’une classe possède sa propre copie des attri-
buts de la classe.
Il est parfois nécessaire de définir un attribut de classe (static en Java ou en
C++) partagé par toutes les instances de la classe.
Les instances peuvent accéder à un attribut de classe mais ils n’ont pas une
copie de lui.
L’accès à cet attribut ne nécessite pas l’existence d’une instance.
Représentation : un attribut de classe est souligné.

14
2.6.3 Attributs dérivés
Les attributs dérivés peuvent être calculés à partir d’autres attributs et de
formules de calcul. Ils sont symbolisés par l’ajout d’un « / » devant leur nom.

NB : Un attribut dérivé peut être traduit par une opération.

15
2.7 Les méthodes
2.7.1- Syntaxe de déclaration des méthodes
Dans une classe, une opération (même nom et même types de paramètres)
doit être unique.
Le nom d’une opération peut apparaît plusieurs fois avec des paramètres dif-
férents, l’opération est dite surchargée.
NB : il est impossible que deux opérations ne se distinguent que par leur va-
leur retournée.
La déclaration d’une opération contient les types des paramètres et le type
de la valeur de retour, sa syntaxe est la suivante :
<visibilité> <nom_méthode> ([<paramètre_1>, ... , <paramètre_N>]) : [<type_renvoyé>]
[{<propriétés>}]

16
1- La syntaxe de définition d’un paramètre (<paramètre>) est la suivante :
[<direction>] <nom_paramètre>:<type> ['['<multiplicité>']'] [=<valeur_par_défaut>]
La direction peut prendre l’une des valeurs suivante :
In (par defaut): Paramètre d’entrée passé par valeur.
out: Paramètre de sortie uniquement. Il n’y a pas de valeur d’entrée et la va-
leur finale est disponible pour l’appelant.
inout : Paramètre d’entrée/sortie. La valeur finale est disponible pour l’appe-
lant.
Le type du paramètre (<type>) peut être un nom de classe, un nom d’interface
ou un type de donné prédéfini.

17
2- Les propriétés (<propriétés>) correspondent à :
• des contraintes
• des informations complémentaires : les exceptions, les préconditions, les
postconditions
• des propriétés définis ci-dessous :
§ requête: l'opération ne modifie pas l'état de l'objet
§ abstrait : l'opération est virtuelle pure (aucun comportement).
§ estFeuille : l’opération ne peut être redéfinie dans les classes
dérivées ;
§ estRacine : l’opération est définie pour la première fois dans
une hiérarchie ;

18
 § concurrence : (séquentiel | gardé | concurrent) précise le mé-
canisme d'exécution concurrente .

La spécification d'une pré-condition qui doit être toujours vraie avant l'exécu-
tion de l'opération.
La spécification d'une post-condition qui est toujours vraie après l'exécution
de l'opération.

19
2.7.2- Méthodes de classe
Une méthode de classe ne peut manipuler que des attributs de classe et ses
propres paramètres. Cette méthode n’a pas accès aux attributs d’instances.
L’accès à une méthode de classe ne nécessite pas l’existence d’une instance
de cette classe.
Graphiquement, une méthode de classe est soulignée.
2.8 Classes Utilitaires
Une classe utilitaires est une classe dont tous les membres ont une protée de
classe : c'est à dire que les opérations et les attributs deviennent des va-
riables et des procédures globales.
Une classe Utilitaire ne peut pas être instanciée et elle est stéréotypée par
<<utilitaire>>.

20
Exemple :

21
2.9 Généralisation et polymorphisme
La généralisation décrit une relation entre une classe générale (classe de base
ou classe parent) et une classe spécialisée (sous-classe).
La classe spécialisée est intégralement cohérente avec la classe de base, mais
comporte des informations supplémentaires (attributs, opérations, associa-
tions).
Un objet de la classe spécialisée peut être utilisé partout où un objet de la
classe de base est autorisé.
Dans le langage UML, ainsi que dans la plupart des langages objet, cette re-
lation de généralisation se traduit par le concept d’héritage.
Le symbole utilisé est une flèche avec un trait plein dont la pointe est un
triangle fermé .
22
Les propriétés principales de l’héritage sont :
• La classe enfant possède toutes les caractéristiques de ses classes parents,
mais elle ne peut accéder aux caractéristiques privées de cette dernière.

23
• Une classe enfant peut redéfinir une ou plusieurs méthodes de la classe
parent.
• Toutes les associations (cette notion sera évoquée plus bas) de la classe
parent s’appliquent aux classes dérivées.
• Une instance d’une classe peut être utilisée partout où une instance de sa
classe parent est attendue. Par exemple, toute opération acceptant un objet
d’une classe Animal doit accepter un objet de la classe Chat.
• Une classe peut avoir plusieurs parents, on parle alors d’héritage multiple.
NB : En UML, la relation de généralisation n’est pas propre aux classes. Elle
s’applique à d’autres éléments du langage comme les paquetages, les acteurs
ou les cas d’utilisation.

24
2.9.1 Méthode abstraite
Une méthode est dite abstraite lorsqu’on connaît son entête mais pas la ma-
nière dont elle peut être réalisée (i.e. on connaît sa déclaration mais pas sa
définition). En UML elle est représenté par la contrainte {abstract}.

25
 2.9.2 Classe abstraite
Une classe est dite abstraite lorsqu’elle :
définit au moins une méthode abstraite
ou lorsqu’elle dérive d’une classe de base abstraite et elle ne définit pas
toutes les méthodes abstraites de cette dernière.

26
NB : On ne peut instancier une classe abstraite : elle a pour objectif de dériver
des nouvelles classes

Une classe abstraite peut très bien contenir des méthodes concrètes.
Une classe abstraite pure ne comporte que des méthodes abstraites.
Pour indiquer qu’une classe est abstraite, il faut ajouter le mot-clef abstract,
sous forme de contrainte, derrière son nom.

2.9.3 Polymorphisme
Le Polymorphisme est un mécanisme permettant de sélectionner d’une façon
dynamique un comportement parmi plusieurs (redéfinies dans une hiérarchie
d’héritage) d’une méthodes, selon le contexte de l’exécution (le type de l’ob-
jet réel de l’objet manipulé).
27
En UML, on modélise ce concept par une redéfinition de la méthodes poly-
morphe dans la hiérarchie d’héritage.

28
2.10 Gestion des Exceptions
On modélise une exception par une classe stéréotypée <<signal>>.
Elle est reliée à son:
1. récepteur par une dépendance stéréotypé <<catch>>.
2. déclencheur par un lien de dépendance stéréotypé <<throw>>

29
3 Relations entre classes
3.1 Notion d’association
Une association est une relation entre deux classes (association binaire) ou
plus (association n-aire), qui décrit les connexions structurelles entre leurs ins-
tances.

NB : Les terminaisons d’associations et les attributs sont deux éléments con-

ceptuellement très proches que l’on regroupe sous le terme de propriété.
30
3.2 Terminaison d’association
Une terminaison d’associations est une extrémité de l’association.
Il n’est pas indispensable de préciser la possession des terminaisons d’asso-
ciations ; sauf dans des cas ambiguës.

31
La présence d’un point implique que la terminaison d’association appartient
à la classe située à l’autre extrémité, l’absence du point implique que la ter-
minaison d’association appartient à l’association.
Dans l’exemple, La terminaison d’association sommet appartient à la classe
Polygone tandis que la terminaison d’association polygone appartient à l’as-
sociation.
NB : Une terminaison d’association peut être paramétrée par les éléments
suivant:

32
nom : Une terminaison d’association peut être nommée (facultatif). Le nom
est situé à proximité de la terminaison. Ce nom est appelée rôle. Une associa-
tion peut donc posséder autant de rôles que de terminaisons.
visibilité : Comme un attribut, une terminaison d’association possède une vi-
sibilité. La visibilité est mentionnée devant le nom de la terminaison.
multiplicité : Comme un attribut, une terminaison d’association peut possé-
der une multiplicité. Elle est mentionnée à proximité de la terminaison.
navigabilité : Pour un attribut, la navigabilité est implicite, navigable, et tou-
jours depuis la classe vers l’attribut. Pour une terminaison d’association, la
navigabilité peut être précisée.

33
3.3 Association binaire et n-aire
Association biaire
Une association binaire est matérialisée par un trait plein entre les classes as-
sociées.

Elle peut être nommée (dans l’exemple ‘’travailler pour’’) , et en cas d’ambi-
guïté, on peut préciser le sens de lecture (▸ ou ◂).
Une association est dite réflexive, quand ses deux extrémités pointent vers la
même classe.

34
Association n-aire
Une association n-aire lie plus de deux classes.

Une classe-association peut être reliée au losange par une ligne discontinue
pour représenter une association n-aire dotée d’attributs, d’opérations ou
d’associations.

35
3.4 Multiplicité
La multiplicité associée à une terminaison d’association déclare le nombre
d’objets susceptibles d’occuper la position définie par la terminaison d’asso-
ciation. Ci-dessous quelques exemples de multiplicité :
• exactement un : 1 ou 1..1
• plusieurs : * ou 0..*
• au moins un : 1..*
• de un à six : 1..6
• en générale, M..N : de M à N
Dans une association binaire, la multiplicité sur la terminaison cible contraint
le nombre d’objets de la classe cible pouvant être associés à un seul objet
donné de la classe source (la classe de l’autre terminaison de l’association).

36
Dans une association n-aire, la multiplicité apparaissant sur le lien de chaque
classe s’applique sur une instance de chacune des classes, à l’exclusion de la
classe-association et de la classe considérée. Par exemple, si on prend une
association ternaire entre les classes (A, B, C), la multiplicité de la terminaison
C indique le nombre d’objets C qui peuvent apparaître dans l’association avec
une paire particulière d’objets A et B.
Remarques :
1. Il faut noter que les multiplicités sont en UML « à l’envers », par référence
à Merise, pour les associations binaires et « à l’endroit » pour les n-aires.
2. Pour une association n-aire, la multiplicité minimale doit en principe,
mais pas obligatoirement, être 0 pour assurer une flexibilité de manipulation.

37
3.5 Navigabilité
La navigabilité indique s’il est possible de traverser une association.
Représentations graphiques de la navigabilité :

Par défaut, une association est navigable dans les deux sens.
Exemple :

Les instances de la classe Produit ne stockent pas de liste d’objets du type

Commande. Inversement, la terminaison du côté de la classe Produit est na-
vigable : chaque objet commande contient une liste de produits.
38
3.6 Classe-association
3.6.1 Définition et représentation
Dans certain cas, une association est caractérisée par des propriétés (dite as-
sociation porteuse de données).
En UML, Les associations ne pouvant posséder de propriété, par contre on a
introduit le nouveau concept de modélisation qui est la classe-association.
Exemple : l’association Emploie entre une société et une personne possède
comme propriétés le salaire et la date d’embauche.

39
les deux propriétés date_embauche et salaire n’appartiennent ni à la société,
qui peut employer plusieurs personnes, ni aux personnes, qui peuvent avoir
plusieurs emplois. Il s’agit de propriétés de l’association Emploie. Cette asso-
ciation est modélisée par une ‘’classe-association’’.
NB : Une classe-association se connecte à deux ou plusieurs classes (c’est une
association) et possède des attributs et des opérations (comme une classe) .
40
 3.6.2 Classe-association pour plusieurs associations
Il n’est pas possible de rattacher une classe-association à plus d’une associa-
tion puisque la classe-association constitue elle-même l’association.
Dans le cas où plusieurs classe-associations doivent disposer des mêmes ca-
ractéristiques, elles doivent hériter d’une même classe possédant ces carac-
téristiques, ou l’utiliser en tant qu’attribut.
3.6.3 Auto-association sur classe-association
Pour exprimer une règle de gestion dans un contexte de l’association, la classe-
association peut être reliée à elle-même par une association réflexive ( auto
association)
Exemple : les employés dans une société respectent une hiérarchie. Une per-
sonne est, en tant qu’employé d’une entreprise donné, le supérieur d’une
autre personne dans le cadre de son emploi pour une entreprise donnée
41
3.6.4 Liens multiples
Plusieurs instances d’une même association ne peuvent lier les mêmes objets.
Cette règle ne doit être bloquante dans certains cas.
Exemple : une même personne peut acheter à des moments différents des
actions d’une même société.

42
La contrainte {bag} qui, placée sur les terminaisons d’association de la classe-
association Actions, indique qu’il peut y avoir des liens multiples impliquant
les mêmes paires d’objets.

Équivalences
Parfois, l’information véhiculée par une classe-association peut être véhiculée
sans perte d’une autre manière.

43
NB. On peut aussi transformer l’association en une classe conceptuelle
(classe Actions dans notre exemple)

44
3.7 Agrégation et composition
3.7.1 Agrégation

Une agrégation modélise une relation tout/partie où une classe constitue un

élément plus grand (tout) composé d’éléments plus petit (partie).
Elle représente une relation d’inclusion structurelle ou comportementale d’un
élément dans un ensemble
Elle peut être porteuse de données (de propriétés).

45
 NB : Une association
simple représente une relation structurelle entre deux classes de même ni-
veau conceptuel (aucune des deux n’est plus importante que l’autre).
• Elle est transitive.
• Elle est conceptuelle,
• Elle ne contraint pas la navigabilité ou les multiplicités de l’association.
• Elle n’entraîne pas de contrainte sur la durée de vie des parties par rap-
port au tout.
46
 3.7.2 Composition
La composition, ou agrégation composite, décrit une contenance structurelle
entre instances. La destruction de l’objet composite implique la destruction
de ses composants.
Une instance de la partie appartient toujours à au plus une instance de l’élé-
ment composite : la multiplicité du côté composite ≤ 1 (i.e. 1 ou 0..1).

47
3.8 Dépendance
Une dépendance est une relation unidirectionnelle exprimant une dépen-
dance sémantique entre des éléments du modèle.
Elle indique que la modification de la cible peut impliquer une modification
de la source.
En pratique, on utilise une dépendance quand une ou plusieurs méthodes
d’une classe utilisent :
• en signature, une autre classe
• instancie un autre classe comme variable locale

48
Exemple :

Parmi les stéréotypes prédéfinie en UML sont :

• Utilisation <<use>>, <<appelle>>, <<crée>> (un objet de la classe source
A instancie un objet de classe destination B).
• Permission <<ami>> : l’élément source ignore la visibilité des propriétés
de la destination

49
• Abstration : <<derive>> l’élément source est défini ou il est calculé à par-
tir d’un élément cible, <<realise>> (l’élément source implémente la spécifica-
tion désignée par la cible).

50
 3.9 Qualification
Un qualificatif est un attribut d’association dont les valeurs partitionnent la liste
des objets reliés par le biais d’une association. C'est a dire que la connaissance
d’un objet et d’une valeur de qualificatif permet de retrouver un ou plusieurs
objets liés à l’autre bout de l’association concernée.
Le qualificatif affine donc l’accès à une instance par navigation sur une associa-
tion. Il ne s’applique évidemment qu’à une multiplicité supérieure à « 1 »
puisqu’on ne peut partitionner une liste composée d’un seul élément.

Exemple 1 : employé employeur

Une personne possède une matricule pour chacun de ses employeurs.
C’est un attribut de l’association, que ne peut être placer dans la classe Emploi.

51
L’attribut matricule sert à référencer un employé au sein de son employeur ;
c’est un identifiant relatif, dont la valeur permet d’accéder à une instance
particulière de Personne, pour une Société donnée.

52
Exemple 2 : Compte bancaire
Un compte dans une banque appartient à au plus deux personnes. c-a-d, une
instance du couple {Banque , compte} est en association avec zéro à deux
instances de la classe Personne.
Mais une personne peut posséder plusieurs comptes dans plusieurs banques :
une instance de la classe Personne peut être associée à plusieurs instances du
couple {Banque , compte}.
Dans tous les cas, un instance du couple {Personne , compte} est en associa-
tion avec une instance
Exemple 3 : Échiquier
Une instance du triplet {Echiquier, rangée, colonne} est en association avec
une instance unique de la classe Case unique de la classe Banque.

53
Inversement, une instance de la classe Case est en association avec une ins-
tance unique du triplet {Echiquier, rangée, colonne}.

54
 3.10. Ajout de Metaclasse
Le metamodèle est un concept qui permet de regrouper dans une classe un en-
semble de caractéristiques d'une autre classe.
Ces caractéristiques permettent de découper l'ensemble des objets instancier de
cette classe en sous classes (catégorie, types, modèle...).
La nouvelle classe obtenue est dite métamodèle. Elle a toutes les caractéristiques
d'une classe normale et elle est stéréotypée par <<metamodel>>.
En pratique, On identifie une classe XX qui possède de nombreuses responsabi-
lités. Certaines ne sont pas propres à chaque instance.
On ajoute la classe TypeXX ou ModeleXX et on répartit les attributs et associations
sur les deux classes. Les classes XX est reliée par une association « * - 1 », souvent
navigable vers TypeXX.

55
La classe TypeXX est qualifiée de métaclasse, car elle contient des informations
qui décrivent la classe XX.
NB : Un objet peut déléguer une partie de ses responsabilités à un autre objet
lié.
Ce concept favorise la réutilisation et il permet de lier de nombreuses instances
de XX à la même instance de TypeXX .

56
Exemple : véhicule, agence , chaufeur et mission

Avant Après

57
3.11 Ajout de contraintes
On peut ajouter des contraintes sur une terminaison d’association :
• {ordered} : Ordonné
• {addonly} : Éliminer la possibilité de suppression
ou entre associations regroupant une ou plusieurs classes communes :
• {ou-exclusif} : à l’une ou
exclusivement à l’autre
• {sous-ensemble} : on ne
participe à l’une des associa-
tions que si on a participé à
l’autre (selon le sens de la
flèche)

58
Il existe un certain nombre de contraintes sur les attributs, telles que celles qui ex-
priment la dérivation des attributs dérivés, Ou les attributs constants :

Le schéma ci-dessous traduit un autre exemple de contrainte entre attributs.

59
NB : les contraintes peuvent être exprimées soit en texte libre, soit en OCL.
L'OCL permet d’exprimer des contraintes sous forme d’expressions booléennes
qui doivent être vérifiées par le modèle.

Exemple 1 : la charge d’un véhicule ne doit pas dépasser la charge maximale de

son type

Exemple 2 : un colis est dans l’état nominal s’il n’a pas donné lieu à la moindre
anomalie.
60
Les contraintes sur les relations de généralisation sont :
• {disjoint} ou {overlapping} : l’intersection entre les sous-ensembles est
vide (disjoint) ou non (il y a des objets en communs)
• {complete} ou {incomplete} : l’union entre les sous-ensembles constitue
l’ensemble de base en entier , ou non
• {leaf} ou {root} : est-ce que c’est la fin de hiérarchie d’héritage ou c’est le
début
61
Exemple

62
4- Classes générique
Un template est un descripteur de classe au moyen de paramètres formels.
C’est une classe paramétrée par d’autres classes.

Ceci permet de définir une famille de classes par liaison des paramètres for-
mels à des valeurs actuelles.
Une classe ne devient effective que lorsque cette liaison est faite
63
Exemple

Code en C++
vs java

64
Le paramètre peut être de type primitif ; Dans ce cas il représente une
constante.

65
5 Interfaces
C’est une description d’un ensemble d’opérations utilisées pour spécifier un
service offert par une classe.
Elle ne contient ni attribut, ni association, ni implémentation des opérations
(toutes les opération sont abstraites/virtuelles pures)
On dit qu’une classe réalise une interface c-a-d elle doit :
• soit implémenter les opérations de l’interface
• soit définir les opérations de l’interface comme opérations abstraites et
par conséquent cette classe devient abstraite elle-même.
Une interface est représentée soit par :
• un classeur stéréotypée <<interface>> dite représentation détaillée
un cercle vide, portant le nom de l’interface, dite représentation synthé-
tique.
66
NB. Une interface doit regrouper un ensemble d’opérations assurant un ser-
vice cohérent.
L’objectif des interfaces est de diminuer le couplage entre deux classeurs.
Une interface doit être réalisée par au moins une classe.
Graphiquement, cela est représenté par un trait discontinu terminé par une
flèche triangulaire avec le stéréotype <<realize>>.

67
• Une classe peut réaliser plusieurs interfaces.
• Une classe peut dépendre d’une interface dite interface requise. On re-
présente ceci par une dépendance stéréotypée <<use>>.

68
NB : La notion d’interface est assez proche de la notion de classe abstraite
avec une capacité de découplage plus grand.
La notion d’interface en UML n’a pas d’implémentation en C++ par contre
elle fortement utilisée en Java et en C#.
En C++, une interface peut être remplacée par une classe ne contenant que
des méthodes virtuelles pures.


69