Chapitre 5

CHAPITRE 5
Modéliser les données du projet par un

diagramme de classes
Ce que vous allez apprendre dans ce chapitre :
• Définition du diagramme de classes

• Visibilité, encapsulation des méthodes et attributs
• Attributs et Méthodes d’instance
• Attributs et méthodes de classe
• Contraintes
• Attributs calculés (dérivé)
• Multiplicité (cardinalité)
• Constructeur et destructeurs
• Modèles de classe
• Relations entre classes
• Classes concrètes et abstraites
• Relation de réalisation et notion d'interfaces
10 heures
CHAPITRE 5
1. Définition du diagramme de classes

2. Visibilité, encapsulation des méthodes et attributs
3. Attributs et Méthodes d’instance
4. Attributs et méthodes de classe
5. Contraintes
6. Attributs calculés (dérivé)
7. Multiplicité (cardinalité)
8. Constructeur et destructeurs
9. Modèles de classe
10. Relations entre classes
11. Classes concrètes et abstraites
12. Relation de réalisation et notion d'interfaces
03 - Modéliser les données du projet par un
Définition du diagramme de classes
Diagramme de classes
▪ La modélisation par les cas d’utilisation (comme expliqué au chapitre 4) donne des descriptions fonctionnelles du système
futur du point de vue des acteurs, avec une description dynamique des scénarios d’exécution.
▪ La conception objet demande principalement une description structurelle, statique, du système à réaliser sous forme d’un
ensemble de classes logicielles, éventuellement regroupées en packages.
▪ 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.
▪ Il permet de fournir une représentation abstraite des objets du système qui vont interagir 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 plusieurs cas
d'utilisation.
▪ C’est une vue statique, car on ne tient pas compte du facteur temporel dans le comportement du système.
▪ Le diagramme de classes permet de modéliser les classes du système et leurs relations indépendamment d'un langage de
programmation particulier.
PARTIE 1
École Nationale des Sciences Appliquées 3

Modéliser la structure interne du système
Diagramme de classes Diagramme de classes de

d’Analyse (DCA) Conception (DCC)
• représenter les classes • Compléter par les

métiers (modèle) classes de Vue, de
issues du Cahier de Contrôle, etc.
Charges • Exemple : classes pour
• Exemple d’un système les interfaces
de gestion de graphiques de
commandes : classes l’application, classe
Client, Commande, Contrôleur pour
Produit contrôler la saisie des
PARTIE 1
données, la sécurité,
etc.
Niveau Analyse Niveau Conception

Représentation graphique d’une classe avec UML

▪ Une classe est représentée par un rectangle (appelé aussi classeur) divisé en 3 compartiments :
• Le 1er compartiment contient le nom de la classe qui représente le type d’objet instancié (1ère lettre en majuscules).
Exemple : Voiture
• Le 2ème compartiment contient les attributs : ce sont les données encapsulées dans les objets de cette classe. Exemple :
vitesse courante, numéro d’immatriculation, etc.
• Le 3ème compartiment contient les opérations (méthodes) : les fonctionnalités/services assurées par les objets de la classe.
Compartiment des attributs Remarque
Compartiment des opérations

• Si la modélisation ne s’intéresse qu’aux relations
PARTIE 1
entre les différentes classes du système (et pas au

Figure 24 : Représentation UML d’une classe
contenu des classes), on peut laisser le 2ème et 3ème
compartiment vide.

Représentation graphique d’une classe avec UML

▪ Exemple : Lecteur MP3
PARTIE 1

CHAPITRE 5

5. Contraintes
Visibilité, encapsulation des méthodes et attributs
Encapsulation
▪ L'encapsulation est un mécanisme consistant à rassembler les données et les méthodes au sein d'une structure (vue
interne de l’objet) en empêchant l'accès aux données par un autre moyen que les services proposés.
▪ Ces services accessibles aux utilisateurs de l'objet définissent ce que l'on appelle l'interface de l'objet (vue externe de
l’objet).
▪ L'encapsulation permet de garantir l'intégrité des données contenues dans l'objet.
PARTIE 1

Visibilité
▪ L'encapsulation permet de définir des niveaux de visibilité des éléments d'un conteneur.
▪ La visibilité déclare la possibilité pour un élément de modélisation de référencer un élément qui se trouve dans un espace de
noms différent de celui de l'élément qui établit la référence.
▪ Elle fait partie de la relation entre un élément et le conteneur qui l'héberge
▪ Le conteneur peut être :
• un paquetage, • élément non encapsulé visible par tous.
public
• une classe
+
• ou un autre espace de noms.
▪ Il existe quatre visibilités prédéfinies : • élément encapsulé visible seulement dans la classe.
protected
#
• élément encapsulé visible dans la classe et dans les
private sous-classes .
PARTIE 1
-
• élément encapsulé visible dans les classes du même
package paquetage.
~

Visibilité des attributs

▪ Dans la pratique, lorsque des attributs doivent être accessibles de l'extérieur, il est préférable que cet accès ne soit pas direct,
mais se fasse par l'intermédiaire d'opérations (Accesseurs getter/setter)
Visibilité private
Visibilité public
Figure 25 : Bonnes pratiques pour la manipulation des attributs

PARTIE 1
Remarque
• Dans une classe, le marqueur de visibilité se situe au niveau de chacune de ses caractéristiques (attributs et
opérations). Il permet d'indiquer si une autre classe peut y accéder.

Démonstration de la visibilité
PARTIE 1

CHAPITRE 5

5. Contraintes
Attributs et méthodes d’instance
Attributs d’instance Métalangage Syntaxe

▪ Syntaxe de déclaration d’un attribut :
• [ ] : partie optionnelle
• < > : partie plus ou moins libre
• ‘ : caractère d’échappement
Définir un attribut d’instance par :
• Un nom : doit être unique dans la classe

• Un type de données : (<type>) peut être un nom de classe, un nom d'interface ou un type
de donnée prédéfini
• Une visibilité
• Une valeur initiale (<valeur_par_défaut>)
• La multiplicité (<multiplicité>) d'un attribut précise le nombre de valeurs que l'attribut
PARTIE 1
peut contenir. On la définit entre []. Par défaut, la multiplicité est de 1.

• Une contrainte : lorsque la multiplicité est > 1, il est possible d'ajouter une contrainte
({<contrainte>}) pour préciser si les valeurs sont ordonnées ({ordered}) ou non ({list}).

Multiplicité d’un attribut

▪ Syntaxe de déclaration d’un attribut :
▪ Exemple : L’attribut sous-titre est optionnel : tous les livres n’ont pas de sous-titre, alors qu’ils ont un titre, une langue, etc.
UML indique ce caractère optionnel en ajoutant une multiplicité [0..1] derrière l’attribut
Livre
- titre : String
- sous-titre : String [0..1]
- ISBN : int
- langue : String
PARTIE 1
- date de parution : Date

- Prix : float
Figure 26 :
Attributs d’une classe Livre avec multiplicité

Méthodes d’instance
▪ Dans une classe, une opération (même nom et mêmes types de paramètres) doit être unique.
▪ Quand le nom d'une opération apparaît plusieurs fois avec des paramètres différents, on dit que l'opération est surchargée
▪ Syntaxe de déclaration d’une méthode:
Définir une méthode d’instance par:

• Un nom de méthode
• Les paramètres avec leur type
• Une visibilité
• Le type de la valeur de retour : peut être un nom de classe, un nom d’interface ou un type
PARTIE 1
de données prédéfini
• Les propriétés (<propriétés>) correspondent à des contraintes ou à des informations
complémentaires comme les exceptions, les pré-conditions, les post-conditions ou encore
l’indication qu’une méthode est abstraite (abstract), etc.

Signature d’une méthode

▪ La signature d’une méthode indique le nombre de paramètres en entrée ainsi que le type des paramètres (string, integer, array,
object...).
Direction des paramètres des méthodes

▪ La syntaxe de définition d'un paramètre (<paramètre>) est la suivante :
La direction de transmission d’un paramètre peut être:
• in : paramètre d'entrée passé par valeur. Les modifications du paramètre ne sont pas
PARTIE 1
disponibles pour l'appelant. C'est le comportement par défaut.

• out : paramètre de sortie uniquement. Il n'y a pas de valeur d'entrée et la valeur finale est
disponible pour l'appelant.
• inout : paramètre d'entrée/sortie. La valeur finale est disponible pour l'appelant.

Exemple : la classe Horloge

▪ La méthode régler(heures : int, minutes : int) : void → L’appelant de la méthode veut affecter les attributs
heures et minutes avec des valeurs qu’il va donner.
▪ La direction des paramètres sera alors in (par défaut) : régler(in heures : int, in minutes : int) : void
PARTIE 1
▪ La méthode getTime(heures : int, minutes : int) : void → L’appelant de la méthode veut récupérer les valeurs
des attributs heures et minutes.
▪ La direction des paramètres sera alors out : getTime(out heures : int, out minutes : int) : void

Valeurs par défauts des attributs et des paramètres des méthodes

▪ On indique les valeurs par défaut des attributs lors de leur construction
▪ et les valeurs par défauts des paramètres des méthodes s’ils ne sont pas clairement spécifiés lors de l’appel.
PARTIE 1

CHAPITRE 5

5. Contraintes
Attributs et méthodes de classe (attributs et méthodes statiques)
Attributs et méthodes statiques

▪ Une classe peut contenir des attributs et des méthodes qui lui sont propres et auxquels on peut accéder sans
nécessairement instancier des objets.
▪ Un attribut de classe n’appartient pas à un objet en particulier mais à toute la classe (il n’est pas instancié avec l’objet).
▪ Il garde une valeur unique et partagée par toutes les instances de la classe.
▪ Une méthode de classe ne peut manipuler que des attributs statiques et ses propres paramètres
▪ Graphiquement, un attribut ou une méthode de classe est représenté par un nom souligné.
PARTIE 1

CHAPITRE 5

5. Contraintes
Attributs calculés (dérivés)
Attributs dérivés
▪ Un attribut dérivé est un attribut dont la valeur peut être calculée à partir d’autres informations disponibles dans le
modèle, par exemple d’autres attributs de la même classe, ou de classes en association.
▪ Cet attribut, qui pourrait donc être considéré comme redondant, est néanmoins gardé par l’analyste s’il correspond à un
concept important aux yeux de l’expert métier.
▪ Il est noté en UML avec un « / » avant son nom et suivi d’une contrainte permettant de le calculer
PARTIE 1

CHAPITRE 5

5. Contraintes
6. Attributs calculés (dérivés)
Multiplicité (cardinalité)
Cardinalité
▪ La multiplicité indique le nombre de valeur que l’attribut peut contenir. L’attribut est souvent un tableau de valeurs statique
ou dynamique (collection).
▪ La multiplicité se note entre crochets [] après le type de valeur que contient l’attribut.
▪ On peut préciser la multiplicité également pour un paramètre de méthode
Cardinalité Signification
au niveau de la signature
0..1 Zéro ou une fois
▪Exemple : Une station météo doit relever la 1..1 Une et une seule fois
température à intervalle de temps régulier. 0..* (ou *) De zéro à plusieurs fois
Elle doit pouvoir stocker 100 relevés.
1..* De une à plusieurs fois
m..n Entre m et n fois
n..n (ou n) n fois

PARTIE 1

CHAPITRE 5

5. Contraintes
Constructeur et destructeurs
Constructeurs et destructeurs
▪ Les stéréotypes peuvent être utilisés pour identifier des opérations particulières comme :
• les constructeurs : stéréotype « create »
• et le destructeur : stéréotype « destroy ».
▪ Dans UML, les constructeurs et les destructeurs sont des méthodes spéciales qui ont le même nom que la classe (Formalisme
Java)
Constructeur
Destructeur
PARTIE 1
Remarque
• Un stéréotype est un mot-clé inventé par les utilisateurs.
• Il existe des stéréotypes définis comme <<include>>, <<create>>, etc.
• Mais on peut créer notre propre mot-clé

CHAPITRE 5

5. Contraintes
Modèles de classe
Modèles de classe
▪ Les modèles (templates) sont une fonctionnalité avancée de l’orientée objet.
▪ Un modèle est une classe paramétrée qui permet ainsi de choisir le type des attributs au besoin suivant le paramètre précisé,
dans le coin supérieur droit dans un rectangle dont les côtés sont en pointillés.
▪ Ces modèles de classes sont particulièrement utiles pour toutes les collections qui stockent des valeurs d’un même type, soit
sous forme de tableaux dynamiques ou de listes.
▪ Exemple : La classe vector
PARTIE 1

CHAPITRE 5

5. Contraintes
Relations entre classes
Relation de dépendance
▪ La dépendance est la forme la plus faible de relation entre classes.
▪ Une dépendance entre deux classes autorise simplement une classe à utiliser des
objets d’une autre classe
▪ Il s’agit d’une relation transitoire, au sens où la première interagit brièvement avec
la seconde sans conserver à terme de relation avec elle (liaison ponctuelle).
▪ La dépendance Notation UML : représentée par un trait discontinu orienté, reliant
les deux classes. La dépendance est souvent stéréotypée par <<use>> (<<utilise
un>>) <<use>>
Une relation de dépendance est habituellement utilisée si :
• Une classe utilise un objet d'une autre classe comme argument dans la signature d’une
méthode
PARTIE 1
• Un objet de l'autre classe est créé à l'intérieur de la méthode.

• Dans les deux cas la durée de vie de l'objet est très courte, elle correspond à la durée
d'exécution de la méthode

Relation de dépendance - Exemple

PARTIE 1

Associations entre classes
▪ Par contre, l’association est une relation plus forte. Elle indique qu’une classe est en relation avec une autre pendant un
certain laps de temps.
▪ La ligne de vie des deux objets concernés ne sont cependant pas associés étroitement (un objet peut être détruit sans que
l’autre le soit nécessairement).
▪ Notation UML : L’association est représentée par un simple trait continu, reliant les deux classes. Le fait que deux instances
soient ainsi liées permet la navigation d’une instance vers l’autre, et vice versa (chaque classe possède un attribut qui fait
référence à l’autre classe).
▪ Il existe plusieurs types d’associations :
Associations
entre classes
PARTIE 1
Association réflexive : Association n-aire :

Association binaire : entre n classes
entre 2 classes entre la classe et elle-
même (n >= 3)

Associations binaire - Implémentation
▪ Une association binaire est matérialisée par un trait plein entre les classes,
▪ Si on veut implémenter l’association dans un langage orienté objet, chaque classe de l’association contiendra une référence
(ou un pointeur) de l'objet de la classe associée sous la forme d’un attribut.
▪ Exemple
PARTIE 1
Implémentation

Associations entre classes

▪ Nous pouvons détailler l’association en indiquant :
Nom de Multiplicité
Rôle Navigabilité
l’association (cardinalité)
PARTIE 1

Associations entre classes – Nom de l’association

▪ L’association peut être orné d’un texte, avec un éventuel sens de lecture, qui permet de nous informer de l’intérêt de cette
relation.
▪ Ce nom n’est absolument pas exploité dans le code.
▪ Le nom d’une association doit respecter les conventions de nommage des classeurs : commencer par une lettre majuscule.
PARTIE 1

Associations entre classes – Rôle des extrémités de l’association

▪ Chaque extrémité d’une association peut être nommée.
▪ Ce nom est appelé rôle et indique la manière dont l’objet est vu de l’autre coté de l’association.
▪ Lorsqu’un objet A est lié à un autre objet B par une association, cela se traduit souvent par un attribut supplémentaire
dans A qui portera le nom du rôle B. (et inversement).
PARTIE 1

Associations entre classes – Multiplicité de l’association

▪ La multiplicité (cardinalité) indique le nombre d’instances de classe étant en relation avec la classe situé à l’autre extrémité
de l’association.
▪ Par défaut, la cardinalité est égale à 1.
Cardinalité Signification
0..1 Zéro ou une fois
1..1 Une et une seule fois
▪ Exemple : 0..* (ou *) De zéro à plusieurs fois
• dans un cours, il y a 1 professeur et plusieurs élèves
1..* De une à plusieurs fois
m..n Entre m et n fois
n..n (ou n) n fois
PARTIE 1
• Une personne travaille pour 1 entreprise et une entreprise emploie 1 ou plusieurs personnes

Associations entre classes – Navigabilité
Navigabilité bidirectionnelle Navigabilité unidirectionnelle
• par défaut • une seule classe possède un attribut qui fait

• chaque classe possède un attribut qui fait référence à l’autre classe
référence à l’autre classe en association. • plus fréquente
• plus complexe à réaliser • la première classe peut solliciter une deuxième et
• A éviter dans la mesure du possible que l’inverse est impossible
• peut se représenter de 3 façons différentes :
• Une croix du coté de l’objet qui ne peut pas être
sollicité
• Une flèche du coté de l’objet qui peut être
sollicité
• Les 2 représentations précédentes à la fois
PARTIE 1

Associations entre classes – Navigabilité

▪ Exemple :
• L’extrémité du côté de la classe Commande n'est pas navigable : les instances de la classe Produit ne stockent pas de
liste d'objets du type Commande.
• L’extrémité du côté de la classe Produit est navigable : chaque objet commande contient une liste de produits.
PARTIE 1

Associations entre classes - Association réflexive
▪ Une association réflexive (ou récursive) : lie une classe avec elle-même
PARTIE 1

Associations reliant plusieurs classes - Classe association

▪ Une association peut apporter de nouvelles informations (attributs et méthodes) qui n’appartiennent à aucune des deux
classes qu’elle relie et qui sont spécifiques à l’association.
▪ Ces nouvelles informations peuvent être représentées par une nouvelle classe attachée à l’association via un trait en
pointillés.
▪ Exemple :
• Lorsqu’une personne utilise un téléphone, il faut pouvoir mesurer la durée de l’appel et savoir à quel moment il a lieu
afin de le tarifier.
• On va ajouter donc deux attributs durée et période tarifaire qui n’appartiennent ni à la classe Personne ni à la classe
Téléphone.
• Ces deux attributs sont mis dans une nouvelle classe (la classe Appel) qui est attachée à l’association.
PARTIE 1

Associations particulières - Composition

▪ La composition indique qu’un objet A (appelé conteneur) est constitué d’un autre objet B.
▪ Cet objet A n’appartient qu’a l’objet B et ne peut pas être partagé avec un autre objet
▪ C’est une relation très forte, si l’objet A disparaît, alors l’objet B disparaît aussi.
▪ Elle se représente par un losange plein du coté de l’objet conteneur
▪ Exemple :
Une voiture est composée d’un châssis. Il ne peut pas être utilisé pour une autre voiture
PARTIE 1

Associations particulières - Agrégation
▪ L’agrégation indique qu’un objet A possède un autre objet B, mais contrairement à la composition, l’objet B peut exister
indépendamment de l’objet A.
▪ La suppression de l’objet A n’entraîne pas la suppression de l’objet B.
▪ Elle se représente par un losange vide du coté de l’objet conteneur
▪ Exemple :
Une voiture est composée de 4 roues et un moteur. Ils peuvent être utilisés pour une autre voiture
PARTIE 1

Relation d’héritage
▪ Le mécanisme d’héritage permet de mettre en relation des classes ayant des caractéristiques communes (attributs et
méthodes) en respectant une certaine filiation.
▪ L’héritage indique qu’une classe B est une spécialisation d’une classe A. La classe B (appelé classe fille, classe dérivée ou
sous classe) hérite des attributs et des méthodes de la classe A (appelée classe mère, classe de base ou super classe).
▪ Notation : Il se représente par un triangle vide afin d’indiquer le sens de la généralisation (inverse de la spécialisation).
▪ Exemple :
PARTIE 1

CHAPITRE 5

5. Contraintes
Classes concrètes et abstraites
Classe concrète
• Possède des instances.

• Elle constitue un modèle complet d'objet
• Tous les attributs et méthodes sont complètements définis
Classes abstraites
• Ne peut pas posséder d'instance directe

• Elle ne fournit pas une description complète
• Elle force le passage par l’héritage pour avoir des sous-classes
concrètes
PARTIE 1
• Elle sert à factoriser des attributs et des méthodes à ses sous-classes

• Une classe abstraite possède généralement des méthodes communes
non définies


▪ En UML, une classe ou une méthode abstraite sont représentées avec une mise en italique du nom de la classe ou de la
méthode.
▪ On peut aussi mettre le stéréotype <<abstract>>
▪ Exemple :
Classe abstraite
PARTIE 1

CHAPITRE 5

5. Contraintes
Relation de réalisation et notion d'interfaces
Relation de réalisation
▪ Comme l'interface n'a qu'un objectif de spécification, au moins un élément d'implémentation (une classe) doit lui être
associée.
▪ La relation de réalisation permet de mettre en relation une classe avec son implémentation.
▪ Graphiquement, la réalisation se représente par un trait discontinu terminé par une flèche triangulaire parfois, mais pas
nécessairement, stéréotypé <<realize>>
Méthodes de
l’interface à définir
PARTIE 1
▪ Attention : Une classe qui réalise (implémente) une interface est dans l'obligation de définir les méthodes décrites par
l'interface (notion de contrat à respecter) comme lorsqu'une classe concrète redéfinie les méthodes abstraites héritées de
sa classe parente abstraite.

Chapitre 5 - Modéliser Les Données Du Projet Par Un Diagramme de Classes - Etd

Transféré par

Droits d'auteur :

Formats disponibles

Chapitre 5 - Modéliser Les Données Du Projet Par Un Diagramme de Classes - Etd

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Chapitre 5 - Modéliser Les Données Du Projet Par Un Diagramme de Classes - Etd

Transféré par

Droits d'auteur :

Formats disponibles

Modéliser les données du projet par un

Ce que vous allez apprendre dans ce chapitre :

• Définition du diagramme de classes

1. Définition du diagramme de classes

École Nationale des Sciences Appliquées 3

Modéliser la structure interne du système

Diagramme de classes Diagramme de classes de

• représenter les classes • Compléter par les

Niveau Analyse Niveau Conception

École Nationale des Sciences Appliquées 4

Représentation graphique d’une classe avec UML

Compartiment des attributs Remarque

Compartiment des opérations

entre les différentes classes du système (et pas au

École Nationale des Sciences Appliquées 5

Représentation graphique d’une classe avec UML

École Nationale des Sciences Appliquées 6

1. Définition du diagramme de classes

École Nationale des Sciences Appliquées 8

École Nationale des Sciences Appliquées 9

Visibilité des attributs

Figure 25 : Bonnes pratiques pour la manipulation des attributs

École Nationale des Sciences Appliquées 10

École Nationale des Sciences Appliquées 11

1. Définition du diagramme de classes

Attributs d’instance Métalangage Syntaxe

Définir un attribut d’instance par :

• Un nom : doit être unique dans la classe

peut contenir. On la définit entre []. Par défaut, la multiplicité est de 1.

École Nationale des Sciences Appliquées 13

Multiplicité d’un attribut

- date de parution : Date

École Nationale des Sciences Appliquées 14

Définir une méthode d’instance par:

École Nationale des Sciences Appliquées 15

Signature d’une méthode

Direction des paramètres des méthodes

La direction de transmission d’un paramètre peut être:

disponibles pour l'appelant. C'est le comportement par défaut.

École Nationale des Sciences Appliquées 16

Exemple : la classe Horloge

École Nationale des Sciences Appliquées 17

Valeurs par défauts des attributs et des paramètres des méthodes

École Nationale des Sciences Appliquées 18

1. Définition du diagramme de classes

Attributs et méthodes statiques

École Nationale des Sciences Appliquées 104

1. Définition du diagramme de classes

École Nationale des Sciences Appliquées 109

1. Définition du diagramme de classes

n..n (ou n) n fois

École Nationale des Sciences Appliquées 111

1. Définition du diagramme de classes

École Nationale des Sciences Appliquées 113

1. Définition du diagramme de classes

École Nationale des Sciences Appliquées 115

1. Définition du diagramme de classes

Une relation de dépendance est habituellement utilisée si :