Chapitre 1

Rappels sur la modélisation UML

 Introduction
• Approche Objet:
– Incontournable: développement des systèmes
logiciels complexes
– Evolution incessante : technologies, besoins
applicatifs
– Mais moins intuitive (naturelle) que la
programmation fonctionnelle -> besoin de
modéliser

2
• Modélisation:
– Apporte une grande rigueur (exactitude)
– Offre une meilleure compréhension
– Facilite la comparaison des solutions de conception
avant leur développement
– Langages de modélisation: s’affranchir des contraintes
des langages de programmation
– Besoin d’une méthode de description et de
développement de systèmes:
• Milieu des années 90: plusieurs dizaines mais aucune ne
prédomine

3
• UML (Unified Modeling Language):
– Unification et normalisation: Booch + OOSE (Object Oriented
Software Engineering) + OMT (Object Modeling Technique)

– Notation graphique pour représenter, spécifier, construire et

documenter les systèmes logiciels
– Objectifs:
• Modélisation de systèmes en utilisant les techniques orientées objet
• Création d’un langage abstrait compréhensible par l’homme et
interprétable par les machines

4
• UML (Suite …)
– S’adresse à toutes les personnes chargées de la
production, du déploiement et du suivi de logiciels
(analystes, développeurs, chefs de projets, architectes…)
– Sert à la communication avec les clients et les utilisateurs
du logiciel
– S’adapte à tous les domaines d’application et à tous les
supports
– Permet de construire plusieurs modèles d’un système,
chacun mettant en valeur des aspects différents :
fonctionnels, statiques, dynamiques et organisationnels

5
• UML (Suite …)
– Notation mais pas une méthodologie
– Processus de développement complets fondés sur
UML:
• Rational Unified Process (RUP): implémentation spécifique
de UP proposée par Rational Software
• MDA (Model Driven Architecture): variante de l’IDM lancée
par l’OMG
– Ne convient pas pour la modélisation de processus
continus (procédés en physique)
– N’est pas formel
– N’est pas un langage de programmation : n’a pas la
rigueur syntaxique et sémantique … malgré UML2
• Produit du code partiel: squelettes de classes (attributs et
signatures de méthode)

6
• UML (Suite …)
– Continuellement enrichi

7
• UML (Suite …)
– Couvre toutes les phases du cycle de vie de
développement d’un système
– Indépendant des langages d’implémentation
– Indépendant des domaines d’application

8
• 14 types de diagrammes UML
– Plusieurs modèles d’un même système selon différents
points de vue.
– Les modèles se complètent et peuvent être assemblés.
– Ils sont élaborés tout au long du cycle de vie (processus)
du développement d’un système.

9
Quelques diagrammes UML

10
 1. Diagramme de cas d’utilisation
(Use Case Diagram)
• Objectifs: Recueillir, analyser et organiser les besoins
• Le maître d’ouvrage:
– Définir et exprimer les besoins
– Valider les solutions proposées par le maître d’œuvre
– Valider le produit livré
• Le maitre d’oeuvre:
– Compétences techniques: savoir-faire va bien au-delà
– Recueille les besoins auprès du maître d’ouvrage
• Discussions, rapports techniques, étude de marché, …
• Question: ai-je toutes les connaissances et les informations pour
définir ce que doit faire le système ?

11
 Cas d’utilisation
• Unité cohérente représentant une fonctionnalité
visible de l’extérieur.
• Réalise un service de bout en bout, avec un
déclenchement, un déroulement et une fin, pour
l’acteur qui l’initie.
• Modélise donc un service rendu par le système,
sans imposer le mode de réalisation de ce
service.

12
• Exemple:

13
• Définitions:
– Un stéréotype représente une variation d’un
élément de modèle existant.
– Un classeur est un élément de modélisation qui
décrit une unité comportementale ou structurelle.
Les acteurs et les cas d’utilisation sont des
classeurs.
– Un cas d’utilisation est dit « interne » s’il n’est pas
relié directement à un acteur.

14
 Relations entre cas d’utilisation
• Deux types de relations :
– Les dépendances stéréotypées
• La relation d’inclusion
• La relation d’extension
– La généralisation/spécialisation

15
 Acteur
• L’acteur est dit « principal » pour un cas
d’utilisation lorsque le cas d’utilisation rend
service à cet acteur.
• Les autres acteurs sont dits « secondaires ».
• Un acteur principal obtient un résultat
observable du système tandis qu’un acteur
secondaire est sollicité pour des informations
complémentaires.

16
• Exemple:

17
• Relations entre acteurs
– La seule relation possible
entre deux acteurs est la
généralisation :
un acteur A est une
généralisation d’un
acteur B si l’acteur A
peut être substitué par
l’acteur B (tous les cas
d’utilisation accessibles à
A le sont aussi à B, mais
l’inverse n’est pas vrai).
18
Regroupement des cas d’utilisation en
paquetages
• Définition: Un paquetage permet d’organiser des
éléments de modélisation en groupe.
Un paquetage peut contenir des classes, des cas
d’utilisations, des interfaces, etc.
• UML permet de regrouper des cas d’utilisation
dans un « paquetage ».
• Le regroupement peut se faire par acteur ou par
domaine fonctionnel.
• Un diagramme de cas d’utilisation peut contenir
plusieurs paquetages et des paquetages peuvent
être inclus dans d’autres paquetages.
19
Exemple:

20
 Espace de noms
• UML est soumis à des règles de nommage qu’il
faut strictement respecter.
• Pour accéder au contenu de paquetages
imbriqués les uns dans les autres, il faut utiliser
les deux-points comme séparateur des noms de
paquetage. Par exemple, si un paquetage B inclus
dans un paquetage A contient une classe X, il faut
écrire A::B::X pour pouvoir utiliser la classe X en
dehors du contexte du paquetage B.

21
• Il est possible de représenter les éléments du
système appartenant au paquetage :
– à l'intérieur de celui-ci:

– à l’extérieur:

22
• Les paquetages peuvent s’imbriquer
(décomposition hiérarchique) mais pas se
chevaucher.
• Un élément du système ne peut appartenir
qu’à un et un seul paquetage.
• Chaque paquetage doit posséder un nom
différent.

23
 Dépendances entre paquetages
• Dépendance de type « import »

 Le paquetage B importe Classe1 et Classe2 (pas la Classe3 qui a une visibilité de

type privée).
 Classe1 et Classe2 ont une visibilité de type public dans le paquetage B.
 Le paquetage C importe Classe1, Classe2 et Classe4.

24
 • Dépendance de type « access » :

 Le paquetage B a accès à Classe1 et Classe2 (pas à Classe3 qui a une visibilité de type
privée).
 Classe1 et Classe2 ont une visibilité de type privé dans paquetage B.
 Le paquetage C a accès à Classe4 (pas à Classe1 et Classe2 qui ont une visibilité de type
privée dans paquetage B).

25
 • Dépendances de type « merge » :

Le paquetage A est fusionné dans le paquetage B (le paquetage A n’est pas modifié alors
que le paquetage B est écrasé pour accueillir la fusion des 2 paquetages).

26
 Description des cas d’utilisation
• Diagramme de séquence, activités, …

• Description textuelle …

27
 Conclusion
• Le diagramme de cas d’utilisation est un premier
modèle d’un système.
• L’objectif de cette phase de la modélisation est
d’identifier les frontières du système et les interfaces
qu’il doit offrir à l’utilisateur.
• Le système est encore une boîte noire à l’architecture
et au mode de fonctionnement interne inconnus.
• En revanche, son interface avec le monde qui l’entoure
est partiellement connue.
• Modéliser la structure interne d’un système:
diagramme de classes.
28
 2. Diagramme de classes
• 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 ensemble
pour réaliser les cas d’utilisation.
• Un même objet peut très bien intervenir dans la réalisation
de plusieurs cas d’utilisation. Les cas d’utilisation ne
réalisent donc pas une partition des classes du diagramme
de classes.
• Un diagramme de classes n’est donc pas adapté (sauf cas
particulier) pour détailler, décomposer, ou illustrer la
réalisation d’un cas d’utilisation particulier.

29
• Il s’agit d’une vue statique car on ne tient pas compte du
facteur temporel dans le comportement du système.
• Le diagramme de classes modélise les concepts du domaine
d’application ainsi que les concepts internes créés de toutes
pièces dans le cadre de l’implémentation d’une
application.
• Chaque langage de Programmation Orienté Objets donne
un moyen spécifique d’implémenter le paradigme objet
(pointeurs ou pas, héritage multiple ou pas, etc.), mais le
diagramme de classes permet de modéliser les classes du
système et leurs relations indépendamment d’un langage
de programmation particulier.

30
• Principaux éléments:
– Classes
– Relations :
• Association
• Agrégation et composition
• Généralisation
• Dépendances:
– Réalisation
– Utilisation

31
 Définitions
• Une classe est une description d’un ensemble
d’objets ayant une sémantique, des attributs,
des méthodes et des relations en commun.
• Un objet est une instance d’une classe.
• Instance plus générale que Objet

32
 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 comportement.
• Etat d’un objet est décrit par:
– les attributs Propriétés (structurelles)
– les terminaisons d’associations
• Les associations sont utilisées pour connecter les classes du
diagramme de classes: 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.

33
• Le comportement d’un objet est décrit par des
opérations.
• Opérations: ce sont des fonctions qui peuvent
prendre des valeurs en entrée et modifier les
attributs ou produire des résultats.
• Une opération est la spécification (déclaration)
d’une méthode.
• Les attributs, les terminaisons d’association et les
méthodes constituent les caractéristiques d’une
classe (et de ses instances).
34
 Représentation graphique
Nom_de_la_classe
• Une classe est un classeur. - attribut_1: type1
• Elle est représentée par un rectangle - attribut_2: type2
+opération_1(): type1
divisé en 3 à 5 compartiments. +opération_2(): void
• Un compartiment des responsabilités Responsabilités

peut être ajouté pour énumérer l’ensemble Exceptions

de tâches devant être assurées par la classe

mais pour lesquelles on ne dispose pas encore assez
d’informations.
• Un compartiment des exceptions peut également être
ajouté pour énumérer les situations exceptionnelles
devant être gérées par la classe.

35
 Encapsulation
• Mécanisme consistant à rassembler les
données et les méthodes au sein d’une
structure 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 l’interface de
l’objet (sa vue externe).
• L’encapsulation permet de garantir l’intégrité
des données contenues dans l’objet.

36
 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érents 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.
• Conteneur: pouvant être un paquetage, une
classe ou un autre espace de noms.
37
• Quatre niveaux de visibilités prédéfinis:
Public ou + : tout élément qui peut voir le
conteneur peut également voir l’élément indiqué.
Protected ou # : seul un élément situé dans le
conteneur ou un de ses descendants 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.

38
Où placer les marqueurs de visibilité?
• Dans une classe, le marqueur de visibilité se situe
au niveau de chacune de ses caractéristiques
(attributs, terminaisons d’association et
opération).
– Il permet d’indiquer si une autre classe peut y accéder.
• Dans un paquetage, le marqueur de visibilité se
situe sur des éléments contenus directement
dans le paquetage, comme les classes et les
paquetages imbriqués.
– Il indique si un autre paquetage susceptible d’accéder
au premier paquetage peut voir les éléments.

39
• 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.
Classe
- attribut_1: int
- attribut_2: string
+set_attribut_1(int) : void
+get_attribut_1() : int
+set_attribut_2(string) : void
+get_attribut_2() : string

40
 Nom d’une classe
• Doit évoquer le concept décrit par la classe.
• Commence par une majuscule.
• On peut ajouter des informations complémentaires 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-clé abstract.
• Syntaxe:
[ <Nom_du_paquetage_1>::...::<Nom_du_paquetage_N> ]
<Nom_de_la_classe> [ { [abstract], [<auteur>], [<date>], ...
}]

41
 Les attributs:
Attributs de la classe, attributs de classe et attributs dérivés

Attributs de la classe
• Représentent les données encapsulées dans les objets
de cette classe.
• Chaque attribut est défini par un nom, un type de
données, une visibilité et peut être initialisé.
• Le nom de l’attribut doit être unique dans la classe.
• Syntaxe: Le type peut être un nom de classe, un nom
d’interface ou un type de donnée prédéfini

<visibilité> [/] <nom_attribut> :

<type> * ’*’<multiplicité>’+’ *,<contrainte>-+ + * =
<valeur_par_défaut> ] La multiplicité d’un attribut précise le nombre de valeurs
que l’attribut peut contenir.

Lorsqu’une multiplicité > 1 , il est possible d’ajouter une contrainte pour préciser si les valeurs sont ordonnées
({ordered}) ou pas ({list}). 42
Attributs de classe
• Par défaut, chaque instance d’une classe possède sa propre copie
des attributs de la classe.
• Les valeurs des attributs peuvent différer d’un objet à un autre.
• Il est parfois nécessaire de définir un attribut de classe (static en
Java ou en C++) qui garde une valeur unique et partagée par toutes
les instances de la classe.
• Les instances ont accès à cet attribut mais n’en possèdent pas une
copie.
• Un attribut de classe n’est pas une propriété d’une instance mais
une propriété de la classe et l’accès à cet attribut ne nécessite pas
l’existence d’une instance.
• Graphiquement, un attribut de classe est souligné.

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

44
 Méthodes
Méthode de la classe
• Dans une classe, une opération (même nom et
même 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.
• En revanche, il est impossible que deux
opérations ne se distinguent que par leur valeur
retournée.
45
 • Syntaxe:
<visibilité> <nom_méthode>
([<paramètre_1>, ... , <paramètre_N>]) :
[<type_renvoyé>] [{<propriétés>}]
[<direction>] <nom_paramètre>:<type> *’*’<multiplicité>’+’+ *=<valeur_par_défaut>]

in : Paramètre d’entrée passé par valeur. Les
modifications du paramètre ne sont pas 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.
Les propriétés correspondent à des contraintes
ou à des informations complémentaires comme
les exceptions, les préconditions, les
postconditions ou encore l’indication
qu’une méthode est abstraite (mot-clef
abstract), etc.
46
Méthode de classe
• Comme pour les attributs de classe, il est possible de
déclarer des 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 de la classe
(i.e. des instances de la classe).
• 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.

47
Méthodes et classes abstraites
• Une méthode est dite abstraite lorsqu’on connaît
son entête mais pas la manière dont elle peut
être réalisée (i.e. on connaît sa déclaration mais
pas sa définition).
• Une classe est dite abstraite lorsqu’elle définit au
moins une méthode abstraite ou lorsqu’une
classe parent contient une méthode abstraite non
encore réalisée.
• On ne peut instancier une classe abstraite : elle
est vouée à se spécialiser.
48
• Une classe abstraite peut très bien contenir
des méthodes concrètes.
• Une classe abstraite pure ne comporte que
des méthodes abstraites.
• En programmation orientée objet, une telle
classe est appelée interface.
• Pour indiquer qu’une classe est abstraite, il
faut ajouter le mot-clé abstract derrière son
nom.
49
 Classe active
• Une classe est passive par défaut, elle sauvegarde les
données et offre des services aux autres.
• Une classe active initie et contrôle le flux d’activités.
• Graphiquement, une classe active est représentée
comme une classe standard dont les lignes verticales
du cadre, sur les côtés droit et gauche, sont doublées.
• Exemple: Un téléphone mobile dispose d’un
gestionnaire d’événements qui permet de suspendre
l’activité du téléphone lorsque celui-ci n’est pas
sollicité, d’afficher un message quand un
rendez-vous est programmé. Proposez une
modélisation UML de ce gestionnaire d’événements.

50
• Le gestionnaire d’événements peut être modélisé
par une classe. L’instance de cette classe crée
elle-même des instances de la classe événements
et contrôle certaines activités du téléphone.
• Le gestionnaire d’événements
contient des événements.
Il est capable de créer
un événement, de le suspendre,
de l’afficher ou de le détruire.

51
 Relations entre classes
• Les relations entre classes expriment les liens
sémantiques ou structurels.
• Les relations les plus utilisées sont :
– l’association,
– l’agrégation,
– la composition,
– la dépendance et
– l’héritage.

52
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 instances.
• Une association indique qu’il peut y avoir des
liens entre des instances des classes
associées.

53
 Comment une association doit-elle
être modélisée ?

Ou bien:

54
• Dans la première version, l’association apparaît
clairement et constitue une entité distincte.
• Dans la seconde, l’association se manifeste par la
présence de deux attributs dans chacune
des classes en relation.
• UML a tranché pour la première version car elle
se situe plus à un niveau conceptuel (par
opposition au niveau d’implémentation) et
simplifie grandement la modélisation
d’associations complexes.

55
Association binaire
• Une association binaire est matérialisée par un
trait plein entre les classes associées.
• Elle peut être ornée d’un nom, avec
éventuellement une précision du sens de lecture
.
• Quand les deux extrémités de l’association
pointent vers la même classe, l’association est
dite réflexive.

56
• Exemple:

57
Association n-aire
• Lie plus de deux classes.
• Est représenté par un grand losange avec un
chemin partant vers chaque classe
participante.
• Le nom de l’association apparaît à proximité
du losange.

58
• Exemple:

59
 Multiplicité
• 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).
• Les principales multiplicités normalisées sont :
– « plusieurs » (*),
– « exactement n » (n),
– « au minimum n » (n..*) et
– « entre n et m » (n..m).
• 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.

60
 Navigabilité
• La navigabilité indique s’il est possible de
traverser une association. On représente
graphiquement la navigabilité par une flèche
du côté de la terminaison navigable et on
empêche la navigabilité par une croix du côté
de la terminaison non navigable.
• Par défaut, une association est navigable dans
les deux sens.

61
Exemple:

• La terminaison du côté de la classe Commande n’est

pas navigable : cela signifie que 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 navigable : chaque objet commande
contient une liste de produits.

62
• Ces 3 notations ont la même sémantique:

63
• Ces 2 modélisations sont équivalentes

• Dans un diagramme de classes, si la classe Point est

présente, il est extrêmement maladroit de représenter
des classes (comme la classe Polygone) avec un ou
plusieurs attributs de type Point. Il faut, dans ce cas,
matérialiser cette propriété de la classe en question
par une ou plusieurs associations avec la classe Point.

64
• Associations réflexives :

• Association avec contraintes OCL:

65
 Qualification
• Quand une classe est liée à une autre classe par une
association, il est parfois préférable de restreindre la
portée de l’association à quelques éléments ciblés
(comme un ou plusieurs attributs) de la classe.
• Ces éléments ciblés sont appelés un qualificatif.
• L’objet sélectionné par la valeur du qualificatif est
appelé objet cible
• L’association est appelée association qualifiée.
• Un qualificatif agit toujours sur une association dont la
multiplicité est plusieurs (avant que l’association ne
soit qualifiée) du côté cible.
66
67
• Un compte dans une banque appartient à au plus deux
personnes (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. C’est-à-dire qu’une instance de la classe
Personne peut être associée à plusieurs (zéro compris)
instances du couple {Banque , compte}.
• Une instance du triplet {Echiquier, rangée, colonne} est en
association avec une instance unique de la classe Case.
• Inversement, une instance de la classe Case est en
association avec une instance unique du triplet {Echiquier,
rangée, colonne}

68
 Classe-association
• Soit l’exemple:

69
• L’association Emploie entre une société et une
personne possède comme propriétés le salaire et la
date d’embauche.
• Ces deux propriétés n’appartiennent ni à la société, qui
peut employer plusieurs personnes, ni aux personnes,
qui peuvent avoir plusieurs emplois.
• Il s’agit bien de propriétés de l’association Emploie.
• Les associations ne pouvant posséder de propriété, il
faut introduire un nouveau concept pour modéliser
cette situation : celui de classe-association.

70
• Une classe-association possède les
caractéristiques des associations et des
classes: elle se connecte à deux ou plusieurs
classes et possède également des attributs et
des opérations.
• Une classe-association est caractérisée par un
trait discontinu entre la classe et l’association
qu’elle représente.

71
• Auto-association sur classe-association

72
• Pour ajouter une association Supérieur de précisant
qu’une personne est le supérieur d’une autre
personne. On ne peut simplement ajouter une
association réflexive sur la classe Personne.
• En effet, une personne n’est pas le supérieur d’une
autre dans l’absolu. Une personne 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.
• Il s’agit donc d’une association réflexive, non pas sur la
classe Personne mais sur la classe-association Emploie.

73
• Liens multiples

74
• Plusieurs instances d’une même association ne
peuvent lier les mêmes objets.
• Cependant, si l’on s’intéresse à l’exemple précédent, on
voit bien qu’il doit pouvoir y avoir plusieurs instances
de la classe-association Actions liant une même
personne à une même société : une même personne
peut acheter à des moments différents des actions
d’une même société.
• C’est la raison de 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.

75
• Classe-association, association n-aire ou
association qualifiée ?

Pour couvrir le cas des comptes joints, il faut utiliser le modèle de droite.

76
Si un cours doit pouvoir exister indépendamment d’un lien entre un enseignant
et un groupe, il faut utiliser le modèle de droite.

77
 Relation d’agrégation
• Relation structurelle entre deux classes de même
niveau conceptuel
• Modélise une relation tout/partie: une classe constitue
un élément plus grand (tout) composé d’éléments plus
petit (partie)
• 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
• Contrairement à une association simple, l’agrégation
est transitive.

78
 Relation d’agrégation
• Elle ne contraint pas la navigabilité ou les
multiplicités de l’association.
• Elle n’entraîne pas de contraintes sur la durée
de vie des parties par rapport au tout.

• Exemple:

Pièce 1 .. * Mur
1.. *

79
 Relation de composition
• Appelée également « agrégation composite »
• Décrit une contenance structurelle entre
instances.
• L’élément composite est responsable de la
création, de la copie et de la destruction de ses
composants.
• La destruction ou la copie de l’objet composite
implique respectivement la destruction ou la
copie de ses composants.
• Une instance de la partie appartient toujours à au
plus une instance de l’élément composite.
80
 Relation de composition
• Graphiquement, : Une composition se
distingue d’une association par l’ajout d’un
losange plein du côté du composite.
• La multiplicité du côté composite ne doit pas
être supérieure à 1

• Exemple:
Repertoire Fichier
1 0 .. *

81
 Relation d’héritage
• 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, associations).
• En UML: relation d’héritage

82
 Relation d’héritage
• Exemple:

83
 Relation d’héritage
Caractéristiques
• 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 ces dernières.
• Une classe enfant peut redéfinir (même signature) une
ou plusieurs méthodes de la classe parent.
– Sauf indication contraire, un objet utilise les opérations les
plus spécialisées dans la hiérarchie des classes.
• Toutes les associations de la classe parent s’appliquent
aux classes dérivées.

84
 Relation d’héritage
Caractéristiques
• Une instance d’une classe peut être utilisée partout où
une instance de sa classe parent est attendue. Par
exemple, en se basant sur le diagramme précédent,
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.
– Implémentation possible en C++ et pas en Java.
• La relation d’héritage n’est pas propre aux classes, elle
s’applique à d’autre éléments du langage UML comme
les paquetages, les acteurs ou les cas d’utilisation.

85
 Relation de dépendance
• Relation unidirectionnelle exprimant une
dépendance sémantique entre des éléments
du modèle.
• Représentée par un trait discontinu orienté.
• Indique que la modification de la cible peut
impliquer une modification de la source.
• Souvent stéréotypée pour mieux expliciter le
lien sémantique entre les éléments du modèle

86
 Relation de dépendance
• On utilise souvent une dépendance quand une
classe en utilise une autre comme argument
dans la signature d’une opération.
• Exemple:

87
 Interfaces
• But: regrouper un ensemble d’opérations assurant un
service cohérent offert par une classe
• Utilisée pour classer les opérations en catégories sans
préciser la manière dont elles sont implémentées
• Contrairement à une classe, une interface ne spécifie
pas une structure interne et ne précise pas les
algorithmes permettant la réalisation de ses méthodes.
• N’a pas d’instances directes
• Pour être utilisée, elle doit être réalisée par une classe

88
 Interfaces
• Graphiquement:

<< realize>>

• Exemple:

89
 Conclusion
• Le diagramme de classes montre un aspect
structurel (approche objet) du système, tandis
que celui des cas d’utilisation montre un côté
fonctionnel.
• D’autres aspects: autres modèles (autres
diagrammes).
• Diagramme de classes: modèle dominant dans
l’Ingénierie Dirigée par les Modèles.

90