II.2.

DIAGRAMME DE CLASSES

Le diagramme de classes décrit la structure statique

du système en termes de classes et de relations entre
ces classes.
Le diagramme de classes représente l’ensemble des
informations finalisées, regroupées dans des classes.
Il est considéré comme le plus important de la
modélisation orientée objet car tout système orienté
objet est organisé autour des classes.
Il est la représentation abstraite des objets du système
qui doivent interagir ensemble pour réaliser les cas
d’utilisation.
08/05/2020 Patrick KASONGA 1
II.2.1. Concepts de base

a) Classe
Une classe est une abstraction d’un ensemble d’objets
ayant les mêmes caractéristiques : elle définit leur
structure, leur comportement et leurs relations.
C’est donc un type d’objets.
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.
Par exemple, Etudiant est une classe, Pétronille est une
instance ou un objet de la classe Etudiant.

08/05/2020 Patrick KASONGA 2

b) Représentation graphique d’une classe
Une classe définit un jeu d’objets dotés de propriétés
statiques (attributs) et dynamiques (opérations). Les
attributs permettent de spécifier son état et les opérations
décrivent son comportement.

Nom_classe
Attribut1 : string
Attribut2 : int
…
Operation1() : void
Operation2() : void
…

08/05/2020 Patrick KASONGA 3

c) Attribut

Une classe se compose d’un ensemble d’informations

élémentaires, appelées attributs de classe.

Un attribut représente la modélisation d’une

information élémentaire représentée par son nom et
son format
Il représente une donnée encapsulée dans les objets de
la classe

08/05/2020 Patrick KASONGA 4

d) Opération ou méthode

Une opération est une fonctionnalité assurée par

une classe.
La description des opérations peut préciser les
paramètres d’entrée et de sortie ainsi que les
actions élémentaires à exécuter. Une méthode de
classe ne peut manipuler que des attributs de classe et
ses propres paramètres

08/05/2020 Patrick KASONGA 5

II.2.2. Encapsulation et visibilité

L’encapsulation est un mécanisme consistant à

rassembler les données et les méthodes au sein d’une
structure 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.

Ces services accessibles (offerts) aux utilisateurs de

l’objet définissent ce que l’on appelle l’interface de
l’objet (sa vue externe).

08/05/2020 Patrick KASONGA 6

II.2.2. Encapsulation et visibilité (suite)

L’encapsulation permet de définir 4 niveaux de visibilité

des éléments d’un conteneur :
- public (+) : l’élément est visible pour tous les clients
de la classe
- protégé (#) : l’élément est visible pour les sous-
classes de la classe
- privé (-) : l’élément n’est visible que par les
objets de la classe dans laquelle il est déclaré.
- package (~) ou rien : seul un élément déclaré dans
le même paquetage peut voir l’élément.

08/05/2020 Patrick KASONGA 7

II.2.3. Relations entre classes
a) Généralisation
La généralisation décrit une relation entre une classe
générale (superclasse ou classe parent ou classe
générique) et une classe spécialisée (sous-classe ou
classe fille).

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, cette relation de généralisation

se traduit par le concept d’héritage.

08/05/2020 Patrick KASONGA 8

Exemple

08/05/2020 Patrick KASONGA 9

b) Association
Une association est une relation entre deux classes
(association binaire) ou plus (association n-aire), qui
décrit les connexions structurelles entre leurs
instances.
Ex :

CLIENT FACTURE

08/05/2020 Patrick KASONGA 10

II.2.4. Multiplicité ou cardinalité
La multiplicité, appelée aussi cardinalité, représente le
minimum et le maximum de fois qu’une instance de
classe participe à l’association.
Autrement dit, elle définit le nombre d’instances de
l’association pour une instance de la classe. Elle est
définie par :
– exactement un : 1 ou 1..1
– plusieurs : * ou 0..*
– au moins un : 1..*
– au plus un : 0..1

08/05/2020 Patrick KASONGA 11

II.2.5. Classe-association
Parfois, un attribut dépend fonctionnellement de 2
identifiants, appartenant à 2 classes différentes. Dans
ce cas, on dit que cette association est porteuse de
propriétés et ces propriétés seront placées dans une
classe-association représentée par un rectangle
suspendu à l’association par des pointillés.

08/05/2020 Patrick KASONGA 12

II.2.6. Associations particulières entre classes
a) L’agrégation
Une agrégation est une association qui représente une
relation d’inclusion structurelle ou comportementale
d’un élément dans un ensemble. Graphiquement, on
ajoute un losange vide ( ) du côté de l’agrégat.

b) La composition, également appelée agrégation

composite, décrit une contenance structurelle entre
instances. Ainsi, 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. Graphiquement, on
ajoute un losange plein ( ) du côté de l’agrégat.
08/05/2020 Patrick KASONGA 13
Exemple

08/05/2020 Patrick KASONGA 14

 TD D’UML
Soit un projet de conception d’une application permettant
d’effectuer des appels téléphoniques dans une cabine
publique. L’application doit permettre à l’utilisateur
d’introduire une pièce de monnaie pour lancer l’appel. Le
lecteur de pièces de monnaie accepte les pièces de 10
centimes, 20 centimes et 50 centimes. Dès que la pièce
introduite est vérifiée, le système émet un long bip et
l’utilisateur peut composer son numéro et effectuer son
appel pendant une durée relative à la valeur de la pièce
introduite. Il existe un administrateur de l’application qui peut
mettre en marche ou arrêter la cabine publique à partir de
son poste et peut afficher et imprimer les relevés d’appel ; il
peut également approvisionner la cabine en unités d’appel.
Pour toutes ses opérations, l’administrateur doit au
préalable taper son login et son mot de passe.
08/05/2020le diagramme de Patrick
Etablir casKASONGA
d’utilisation système 15
Soit un projet permettant la vente du carburant par carte
bancaire dans une station de pompage qui possède 4 pompes.
L’application doit permettre au client d’introduire sa carte
bancaire dans un lecteur de carte bancaire incorporé à la
pompe (ou distributeur d’essence), de taper le code pin à 4
chiffres et de taper le montant désiré pour le carburant
souhaité. Si le code est correct et que la carte est assez
approvisionnée, le pistolet de la pompe est déclenché et le
client peut se servir lui-même le carburant. Le gérant de la
station contrôle les pompes (il peut les activer ou les
désactiver à partir de son poste), il enregistre les entrées en
stocks pour faire la mise à jour des stocks et vérifie le niveau
de stocks. Dès que le niveau minimal est atteint, l’application
envoie un signal d’alerte ; Le gérant peut aussi éditer des
rapports générés par l’application, il doit s’authentifier pour tout
ce qu’il peut faire
08/05/2020 Patrick KASONGA 16
Travail demandé

1. Etablir le diagramme de cas d’utilisation

système
2. Etablir le diagramme de classes du domaine
3. Etablir un diagramme de classes participantes
pour chaque cas d’utilisation

08/05/2020 Patrick KASONGA 17

II.2.7. Types de diagrammes de classes

Il existe 3 types de diagrammes de classes :

 Le diagramme de classes du domaine appelé
simplement modèle du domaine
 Le diagramme de classes participantes
 Le diagramme de classes de conception

08/05/2020 Patrick KASONGA 18

a. Modèle du domaine

C’est un diagramme de classes qui modélise les

concepts-clés du domaine étudié.
Il s’agit de l’ensemble des objets qui concourent à
la réalisation des activités du métier du domaine.
La structure interne du domaine conduit à la
création de la base de données ou des fichiers.

Comment le trouver?

08/05/2020 Patrick KASONGA 19

a. Modèle du domaine (suite)

 Identifier les concepts ou entités du domaine en

tant que classes
 Y rattacher des attributs
 Ajouter les associations et les multiplicités
 Simplifier le modèle en utilisant l’héritage
 Structurer éventuellement les classes en
paquetages selon les principes de cohérence et
d’indépendance

08/05/2020 Patrick KASONGA 20

b. Le diagramme de classes participantes
Le modèle du domaine doit être indépendant
des utilisateurs et des interfaces graphiques.
Ainsi, l’application doit être découpée en 3
couches : Présentation, Logique applicative et
Données.
Le diagramme de classes participantes modélise
justement l’ensemble de classes d’analyse qui
concourent à la réalisation d’un cas d’utilisation.

08/05/2020 Patrick KASONGA 21

Ces 3 types de classes d’analyse sont :
Les classes de dialogues : elles représentent les
interactions entre les utilisateurs et les IHM. Il y a au
moins un dialogue pour une association entre un
acteur et un cas d’utilisation.
Les classes de contrôles : elles modélisent le métier
ou encore la logique applicative de l’application pour
manipuler les informations détenues par un objet
métier et relient les dialogues et les entités.
Les classes Entités : elles sont persistantes en ce
sens qu’elles survivent à l’exécution des cas
d’utilisation. Elles proviennent du modèle du domaine
et permettent le stockage des données dans des
fichiers ou dans des bases de données.
08/05/2020 Patrick KASONGA 22
Exemple

08/05/2020 Patrick KASONGA 23

N.B.
Les classes de dialogues ont des attributs et des
méthodes
Les classes de contrôles n’ont que les méthodes
Les classes Entités ont uniquement des attributs
sans méthodes

08/05/2020 Patrick KASONGA 24

c. Le diagramme de classes de conception
Ce diagramme représente la dernière version
du diagramme de classes qui servira à
l’implémentation de l’application.
Dans ce diagramme, on modélise tous les
objets nécessaires à la mise en œuvre de
l’application en ajoutant aussi les opérations

08/05/2020 Patrick KASONGA 25