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
Le diagramme de classes UML

10
• 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.
• Le diagramme de classes est essentiel dans l’IDM
– Représentation: modèle, méta-modèle, …

11
• 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.

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

13
 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

14
 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
– 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.
• Il est possible que selon l’association, une classe joue un rôle différent. La
terminaison d’une association indique par conséquent l’implication de la classe
dans l’association,
• Le rôle décrit comment une classe voit une autre classe au travers d’une
association.
• Il prend tout son intérêt lorsque plusieurs associations existent entre 2 classes.
• L’instance d’une association est appelée un lien.

15
16
• 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).
17
 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.

18
 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.

19
 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.
20
• 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.

21
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.

22
• 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

23
 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>], ...
}]

24
 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}). 25
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é.

26
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.

27
 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.
28
 • 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.
29
30
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.

31
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.
32
• 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.
33
 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.

34
• 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.

35
 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.

36
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.

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

Ou bien:

38
39
• 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.

40
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.

41
• Exemple:

42
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.

43
• Exemple:

44
 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.

45
 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.

46
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.

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

48
• 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.

49
• Associations réflexives :

• Association avec contraintes OCL:

50
 Association avec contraintes OCL
• Exemples de contraintes portant sur les instances des
classes, à une extrémité d’une association:
– {ordered} ou {ordonné} : Les objets doivent être ordonnés. Rq :
on ne sait pas comment cela sera ordonné (c’est un choix de
conception)
– {frozen} ou {gelé} : Un lien ne peut plus être modifié ni détruit
après sa création
– {addOnly} : On ne peut qu’ajouter un objet, pas le détruire,
– {subset} : indiquant qu’une occurrence fait partie
obligatoirement des occurrences d’une autre association
– {xor} ou {ou-exclusif- : indique qu’une instance ne peut
appartenir en même temps à la réalisation de deux associations.

51
• Un Comité possède plusieurs personnes (membres), mais au moins 2; le
Comité possède un président qui fait nécessairement partie du Comité.

52
• Une Personne veut visiter ou pas des pays (ordre traduisant sa préférence) ; il est
né dans un pays (qui ne changera jamais) ; il a visité un certain nombre de pays
(peut-être aucun), on ne peut qu’en ajouter, et ces pays visités sont ordonnés
(selon par exemple leur date de visite).

53
 Qualification
• Une qualification consiste à sélectionner un sous-ensemble
d'objets parmi l’ensemble des objets qui participent à une
relation.
• 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. 54
• 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}.
• Un objet qualifié et une valeur de
qualificatif génèrent un objet cible lié qualificatif

unique (ou de multiplicité donnée, ici 2). En

considérant un objet qualifié (dans
l’exemple, la banque qualifiée d’un numéro
de compte donné), chaque valeur de
qualificatif désigne un objet cible quasi
unique (un client). 55
• 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}

56
 Classe-association
• Soit l’exemple:

57
• 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.

58
• 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.

59
• Auto-association sur classe-association

60
• 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.

61
• Liens multiples

62
• 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.

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

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

64
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.

65
 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.

66
 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.. *

67
 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.
68
 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 .. *

69
 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

70
 Relation d’héritage
• Exemple:

71
 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.

72
 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.

73
 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

74
 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:

75
 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

76
 Interfaces
• Graphiquement:

<< realize>>

• Exemple:

77
 Élaboration et implémentation d’un
diagramme de classes
• Une démarche couramment utilisée pour bâtir
un diagramme de classes est la suivante :
1. Pour identifier les classes, souligner tous les
termes décrivant le domaine applicatif
(cours, salles, professeurs… pour une
application gérant un Emploi du Temps) ;

78
2. Réduire l'ensemble obtenu avec les critères suivants :
– supprimer des synonymes,
– supprimer des classes trop vagues (elles sont surement
ailleurs),
– supprimer des classes non pertinentes pour l’application,
– découvrir les associations exprimant l'interdépendance
des classes, et les nommer ;
– trouver les attributs des classes, vérifier que chaque
attribut caractérise bien la classe dont on parle (pas
d’identifiant Client dans une classe Commande !).
– identifier les opérations des classes : association ou
attribut ?

79
3. Inclure les relations de généralisation/spécialisation
4. Placer des agrégations/compositions si nécessaire
5. Factoriser avec des interfaces
6. Utiliser les contraintes
7. Réorganiser le diagramme de classes en construisant
des packages
8. Vérifier l’atteignabilité de tous les éléments (se poser
des questions sur les fonctionnalités utilisateurs : par
ex. pour une application marchande, est-ce que je
peux connaître les éléments de mon panier, en
transitant par les différentes associations du
diagramme de classes ?)
80
9. Valider le modèle obtenu avec les utilisateurs
10.Incrémenter le modèle (en itérant) : on
n’obtient jamais le bon diagramme de classes
dès le premier coup (A partir de la 3ieme
itération, on peut penser être proche d’un
diagramme correct).

81
 Implémentation d’un diagramme de
classes en Java
• Dans la majorité des cas, le diagramme de classes sert
à préparer l’implémentation dans un langage cible :
vous construisez votre diagramme de classes à l’aide
d’un AGL (Atelier de Génie Logiciel) et
vous spécifiez le langage cible (Java, Python, PHP, C++,
C#...).
– Exp d’AGL: ArgoUML, Eclipse, Kdevelop, StarUML, …
• Ensuite vous générez le code obtenu : vous obtenez
ainsi le squelette de vos classes, avec les
constructeurs et les accesseurs (get/set) des attributs
automatiquement implémentés, ce qui
simplifie grandement le travail.

82
• Voici une illustration du type de code obtenu
pour certains éléments du diagramme de
classes.

83
84
85
 Conclusion
• Le diagramme de classes montre un aspect
structurel (approche objet) du système,
• D’autres aspects: autres modèles (autres
diagrammes).
• Diagramme de classes: modèle dominant dans
l’Ingénierie Dirigée par les Modèles.

86