Telechargé par hadjer kaddour

08 Diagramme de classes

publicité
Modélisation et conception orientées objet
avec UML
Ilhem Boussaïd
[email protected]
Université des Sciences et de la Technologie Houari Boumediene
Licence 3 Académique
http://sites.google.com/site/ilhemboussaid
18 novembre 2013
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
1 / 101
Introduction
Plan
1
Introduction
Qualité d’une conception
Démarche fonctionnelle
Démarche orientée objet
2
Diagramme de classes
Classes et instances
Relations entre classes
Compléments sur la modélisation des classes
3
Diagramme de packages
4
Références
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
2 / 101
Introduction
De la spécification à la conception
Spécifier → c’est définir le quoi.
Concevoir → c’est définir le comment.
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
3 / 101
Introduction
Principes de conception
La décomposition en sous-problèmes
Il s’agit de :
Décorréler les problèmes pour n’en traiter qu’un seul à la fois.
Simplifier les problèmes (temporairement) pour aborder leur
complexité progressivement.
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
4 / 101
Introduction
Principes de conception
La modularité
C’est une instance cruciale du principe de décomposition des
problèmes.
Il s’agit de partitionner le logiciel en modules qui :
ont une cohérence interne (des invariants) ;
possèdent une interface ne divulguant sur le contenu du module que
ce qui est strictement nécessaire aux modules clients.
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
5 / 101
Introduction
Critères d’évaluation pour la conception
On mesure la cohésion ("cohesion") d’un module aux nombres de ses
sous-modules qui effectuent des tâches similaires et ont des
interactions continues.
On mesure l’interdépendance ("coupling") entre deux modules A et
B à la quantité de modifications à faire sur B lorsque A est modifié
(et réciproquement).
Haute cohésion, basse interdépendance ("High cohesion, low coupling")
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
6 / 101
Introduction
Qualité d’une conception
Qualité d’une conception
La composante la plus importante de la qualité d’une conception est la
maintenabilité.
maximiser la cohésion à l’intérieur des composants
minimiser le couplage entre ces composants
Les dégradations de la conception sont liées aux modifications des
spécifications,
Ces modifications sont à faire vite et par d’autres que les concepteurs
originaux
ça marche mais sans respect de la conception initiale
corruption de la conception (avec effet amplifié au fur et à mesure)
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
7 / 101
Introduction
Qualité d’une conception
Couplage/Cohésion
A RETENIR ABSOLUMENT
Pour qu’un logiciel soit extensible et réutilisable, il faut qu’il soit
découpé en modules
faiblement couplés et
à forte cohésion.
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
8 / 101
Introduction
Qualité d’une conception
Couplage
Couplage
Une entité (fonction, module, classe, package, composant) est couplée
à une autre si elle dépend d’elle.
Couplage faible
Désigne une relation faible entre plusieurs entités (classes,
composants), permettant une grande souplesse de programmation, de
mise à jour.
Ainsi, chaque entité peut être modifiée en limitant l’impact du
changement au reste de l’application.
Couplage fort
au contraire, tisse un lien puissant qui rend l’application plus rigide à
toute modification de code.
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
9 / 101
Introduction
Qualité d’une conception
Couplage fort
Couplage Fort
Mesurez l’impact d’une
modification de ces modules
Module 1
Module 2
Module 4
I. BOUSSAID (USTHB)
Module 3
Module 6
Module 5
GL - COO
18 novembre 2013
10 / 101
Introduction
Qualité d’une conception
Couplage faible
Couplage Faible
Module 1
Module 2
Module 4
I. BOUSSAID (USTHB)
Mesurez l’impact de modification
d’un des modules
Module 3
Module 6
Module 5
GL - COO
18 novembre 2013
11 / 101
Introduction
Qualité d’une conception
Forte cohésion
Cohésion entre modules dans un composant, entre services dans un
module :"qui se ressemble s’assemble "
L’idée est de vérifier que nous rassemblons bien dans une classe des
méthodes cohérentes, qui visent à réaliser des objectifs similaires.
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
12 / 101
Introduction
Qualité d’une conception
Conception : Approche Fonctionnelle vs.
Objet
Comment décomposer ?
Deux approches :
Fonctionnelle → Descendante.
Objet → Ascendante
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
13 / 101
Introduction
Démarche fonctionnelle
Modélisation par décomposition fonctionnelle
descendante
La forme la plus immédiate pour décrire un travail à effectuer est de
lister les actions à réaliser.
On découpe une tâche complexe à effectuer en une hiérarchie
d’actions à réaliser de plus en plus simples, petites et précises (Pour
décrire, on utilise le verbe) :
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
14 / 101
Introduction
Démarche fonctionnelle
Modélisation par décomposition fonctionnelle
descendante
Exemple :
1 Rouler En Voiture :
1
Mettre moteur en marche :
1
2
2
Démarrer Voiture :
1
2
3
3
Mettre Contact
Démarrer Moteur
Mettre Point Mort
Passer La Première
Embrayer En Accélérant
Rouler :
1
2
3
Accélérer
Freiner
Passer Vitesse
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
15 / 101
Introduction
Démarche fonctionnelle
Modélisation par décomposition fonctionnelle
Découpe fonctionnelle descendante 2/9
descendante
Rouler en voiture
Mettre moteur en marche
Mettre contact
Démarrer moteur
Introduire Clé de
contact
Tourner clé de contact
en position
« Démarreur » et la
laisser revenir
Tourner le clé en
position contact
Démarrer
Point mort
Passer la 1ere
Rouler
Embrayer
en accélérant
Levier de vitesse
sur position 1
Accélérer
Suivant pression
pédale de droite
Augmenter le
débit d’essence
dans le
carburateur
I. BOUSSAID (USTHB)
ESISAR
GENIE LOGICIEL
ORIENTE OBJET GL -– COO
Freiner
Passer
vitesse
Suivant pression
pédale du milieu
Augmenter la
pression sur les
freins
18 novembre 2013
16 /7 101
Introduction
Démarche fonctionnelle
Découpe
fonctionnelle
desce
Modélisation par
décomposition
fonctionnelle
descendante
L’implémentation en code source d’une sol
en
programmation procédurale):
L’implémentation en code source d’une solution décrite en terme d’actions
terme d’actions est un code organisé
est un code organisé en fonctions (programmation procédurale) :
roulerEnVoiture()
mettreMoteurEnMarche()
mettreContact()
demarrerMoteur()
demarrer()
mettrePointMort()
passerLaPremiere()
embrayerEnAccelerant()
rouler()
accelerer()
freiner()
passerVitesse()
I. BOUSSAID (USTHB)
ESISAR
GL - COO
GENIE LOGICIEL – ORIENTE OBJET 18 novembre 2013
17 / 101
Introduction
Démarche fonctionnelle
Modélisation par décomposition fonctionnelle
descendante
Dans ce cadre de travail :
L’analyse est une découpe fonctionnelle descendante des
fonctionnalités à pourvoir.
La conception est une découpe du logiciel en une hiérarchie
descendante d’actions permettant de satisfaire les fonctionnalités à
pourvoir.
L’implémentation est une programmation procédurale.
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
18 / 101
Introduction
Démarche fonctionnelle
Modélisation par décomposition fonctionnelle
descendante
Découpe fonctionnelle descendante 5/9
Dans
une programmation
procédurale
issue
d’unedécoupe
découpe fonctionnelle
Dans une
programmation
procédurale
issue
d’une
fonctionnelle descendante, les données et les fonctions
descendante,
les données
les fonctions
travaillant
données
travaillant
sur ceset
données
sont dispersées
danssur
desces
modules
sont dispersées
dans
des
modules
différents.
différents.
type typeVitesse est {pointMort, premiere, seconde, troisieme, quatrieme
cinquieme, marcheArriere};
vitesseCourante : typeVitesse := pointMort;
procedure passerVitesse(
vitesseCourante : in out typeVitesse;
vitesseAPasser : in typeVitesse);
procedure mettreAuPointMort(
vitesseCourante : in out typeVitesse);
ESISAR
I. BOUSSAID (USTHB)
GENIE LOGICIEL – ORIENTE OBJET E.CHENU
GL - COO
10
18 novembre 2013
19 / 101
Introduction
Démarche fonctionnelle
Modélisation par décomposition fonctionnelle
descendante
Dispersion données/fonctions :
Lorsque le logiciel évolue, il faut faire évoluer les structures de données
et les fonctions en parallèle (probablement dans des modules
différents).
Maintenir cette cohérence est laborieuse parce que données et
fonctions sont dispersées.
La dispersion données/fonctions nuit à l’extensibilité !
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
20 / 101
Introduction
Démarche fonctionnelle
Modélisation par décomposition fonctionnelle
descendante
Rappelez vous !
Pour qu’un logiciel soit extensible et réutilisable, il faut qu’il soit découpé
en modules
faiblement couplés, ainsi chaque entité peut être modifiée en
limitant l’impact du changement au reste de l’application. et
à forte cohésion. Il faut réunir ce qui est impacté par une même
modification (« qui se ressemble s’assemble »)
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
21 / 101
Introduction
Démarche fonctionnelle
Modélisation par décomposition fonctionnelle
descendante
Comment évaluer la découpe fonctionnelle descendante et la
programmation procédurale en termes de couplage et cohésion ?
Séparer données et fonctions sur ces données entraine :
Un fort couplage par les données,
Perte de cohésion (par dispersion).
Le code est donc peu extensible et peu réutilisable !
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
22 / 101
Introduction
Démarche fonctionnelle
Fonctionnel versus Objet
2.2 QU’APPORTE LA MODELISATION OBJET
–
–
Plus grande indépendance du modèle par rapport aux fonctionnalités demandées.
ÆDes fonctionnalités peuvent être rajoutées ou modifiées, le modèle objet ne
change pas.
Plus proche du monde réel.
LA DEMARCHE FONCTIONNELLE
Accent mis sur ce que fait le système (ses
fonctions)
LA DEMARCHE OBJET
Accent mis sur ce qu'est le système (ses composants) :
les objets
5
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
23 / 101
Introduction
Démarche orientée objet
Démarche orientée objet
On ne raisonne plus en termes d’actions mais plutôt en concepts du
monde physique.
Puisqu’ils appartiennent au monde physique, ces concepts peuvent être
stables
et
réutilisables.
U
M
G
L
1
NIVERSITE
ENTOURI
ENIE
OGICIEL
FACULTE DES SCIENCES DE L’INGENIEUR
DEPARTEMENT D’INFORMATIQUE
ANNEE UNIVERSITAIRE 2007-2008
ILHEM BOUSSAID
On ne raisonne uniquement en verbes, mais davantage en noms.
2.2 ENCAPSULATION
I. BOUSSAID On
(USTHB)
COO et les comportements (qui
18 novembre
dit que les informations (qui sont GL
des -données)
sont les 2013
24 / 101
Introduction
Démarche orientée objet
Pourquoi une structuration orientée objet ?
Unicité et universalité du paradigme
Réduire le décalage entre monde réel et logiciel
Objets réels → Objets conceptuels → Objets logiciels
Réutilisabilité et évolutivité facilitées par différents
mécanismes
Encapsulation, Modularité, Abstraction, Polymorphisme, Héritage
Faible couplage inter-objets / Forte cohésion intra-objet
Paradigme qui arrive à maturité
Bibliothèques de classes, Design patterns, UML, Méthodologies de
développement (USDP, Agile, XP, ...), ...
Environnements de développement intégrés (IDE)
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
25 / 101
Diagramme de classes
Plan
1
Introduction
Qualité d’une conception
Démarche fonctionnelle
Démarche orientée objet
2
Diagramme de classes
Classes et instances
Relations entre classes
Compléments sur la modélisation des classes
3
Diagramme de packages
4
Références
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
26 / 101
Diagramme de classes
Objectif
Les diagrammes de cas d’utilisation modélisent à QUOI sert le
système.
Le système est composé d’objets qui interagissent entre eux et avec les
acteurs pour réaliser ces cas d’utilisation.
Les diagrammes de classes permettent de spécifier la structure
statique d’un système, en termes de classes et de relations entre ces
classes.
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
27 / 101
Diagramme de classes
Classes et instances
Objets
Objet
Identité + Etat + Comportement
Une identité
deux objets différents ont des identités différentes
on peut désigner l’objet (y faire référence)
Un état (attributs)
ensemble de propriétés/caractéristiques définies par des valeurs
permet de le personnaliser/distinguer des autres objets
peut évoluer dans le temps
Un comportement (méthodes)
ensemble des traitements que peut accomplir un objet (ou que l’on
peut lui faire accomplir)
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
28 / 101
Diagramme de classes
Classes et instances
Objets
Objet : Entité concrète ou abstraite du domaine d’application. Décrit par
état (attributs) + comportement (opérations)
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
29 / 101
Diagramme de classes
Classes et instances
Objets - Exemple
Objet (2)
y Quelques exemples:
9
Objet
États
Comportements
Chien
Nom, race, âge, couleur
Aboyer, chercher le baton,
mordre, faire le beau
Compte
N°, type, solde, ligne de crédit
Retrait, virement, dépôt,
consultation du solde
Téléphone N°, marque, sonnerie, répertoire,
opérateur
Appeler, Prendre un appel,
Envoyer SMS, Charger
Voiture
Tourner, accélérer, s’arrêter,
ffaire
i lle plein,
l i kl
klaxonner
Plaque, marque, couleur, vitesse
USTHB - Master IL 2009-2010
I. BOUSSAID (USTHB)
- GL
Ilhem
BOUSSAID
- COO
18 novembre 2013
30 / 101
Diagramme de classes
Classes et instances
Classes et instances
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
31 / 101
Diagramme de classes
Classes et instances
Classes et instances
Les objets possédant la même structure de données (attributs) et
le même comportement (opérations) sont les représentants d’une
même classe.
Une classe est une abstraction qui décrit les propriétés pertinentes
pour une application.
Données et opérations traitant les données ne sont pas séparées, mais
réunies au sein d’un même module. Cohésion !
Chaque objet est une instance d’une classe.
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
32 / 101
Diagramme de classes
Classes et instances
Classes et instances
Classe : Regroupement d’objets de même nature (mêmes attributs +
mêmes opérations)
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
33 / 101
Diagramme de classes
Classes et instances
Classes et instances
Classes et instances (2)
Layclasse
« chien
» définit :
Quelques
exemples
LesLaattributs
d’un» définit:
chien (nom, race, couleur, âge, . . . )
y
classe « chien
Lesy comportements
d’un
chien
chercher le bâton, mordre. . . )
Les attributs d’un chien
(nom,
race,(Aboyer,
couleur, âge…)
Les comportements
d’un chien
(Aboyer, chercher
bâton,
mordre…) de chien
Il peut yexister
dans le monde
plusieurs
objetsle(ou
instances)
y Il peut exister dans le monde plusieurs objets (ou instances) de chien
Classe
Instances (Objets)
Chien
Mon chien: Bill, Teckel, Brun, 1 an
Le chien de mon voisin: Hector, Labrador, Noir, 3 ans
Compte
Mon compte à vue: N° 210-1234567-89, Courant, 1.734 DZ,
12.500DZ
Mon compte épargne: N° 083-9876543-21, Epargne, 27.000 DZ, 0DZ
Voiture
Ma voiture: ABC-123, VW Polo, grise, 0 km/h
La voiture que je viens de croiser: ZYX-987, Porsche, noire, 170 km/h
11
USTHB - Master IL 2009-2010 - Ilhem BOUSSAID
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
34 / 101
Démarche de
conception OO
Diagramme
conceptionde
OOclasses
implémentation, etc.)
Classes et instances
conception OO
Figure 7.10 - Features diagram of the Kernel package
Représentation d’une classe
75
76
76
rectangle composé de compartiments
Compartiment 1 : Nom de la classe (commence par une majuscule, en
Méthode de
Méthode de
gras)
Conception
Conception
Orientée Objet
ramme de classes
Diagramme
de
classes
Orientée
Objet
Compartiment 2 : Attributs
Diagramme de classes
A. Lewandowski
Classe
Attributs et
A. Lewandowski
A. Opérations
Lewandowski
Compartiment
3 : Opérations
Classe
Méthode de
Conception
Orientée Objet
d’ajouter des compartiments
(exceptions, ...)
tions etPossibilité
méthodes
Résumé
Représentation des attributs :
on est une fonction
ou une
procédure
UML Superstructure
Specification,
v2.1.1 qui peut
uée aux objets ou par les
d!une classe. Introduction
Uneobjets
classe
30
UML Superstructure Specification, v2.1.1
Représentation
Introduction
Introduction
pération
peut s!appliquer à de nombreuses d’une
Conceptsclasse
de base
initiale {
visibilité nom : type
= valeur
nts
Une[multiplicité]
classe
Attribut 1
érentes. Dans ce cas, on dit qu!elle est
Diagrammes
UML
Concepts
de
base
Concepts de base
Attribut
2
•
rectangle à 3 Introduction
compartiments
eule)
.
Attribut
1
à UML
UML Opération
Diagrammes UML
deDiagrammes
est l!implémentation
d!une 1opération
pour(singulier,
Diagramme de cas
Attribut 2
• nom
d’utilisation majuscule)
donnée.
Opération 2
Introduction à UML
Introduction à UML
Diagramme de classes
Opération
1
Diagramme de cas
Diagramme de cas
• attributs Diagramme de
facultatif
public +
d’utilisation
d’utilisation
packages
Opération
2
facultatif
de classes
Diagramme de classes
privé • opérations
Diagramme d’objets
enDiagramme
fonction
des
besoins
par défaut: 1
Diagramme de
Diagramme de
Diagramme de
protégé
#
communication
packages
packages
[0..1] élément pouvant être
nul
Argument :
Diagramme de
Diagramme d’objets
Diagramme d’objets
•
plus
ou
moins
de
détails
en
fonction
des
besoins
séquence
[4]
tableau
de 4 élémentsDiagramme de
sensDeFlux
nomArgument
:
type
=
valeurParDéfaut
Diagramme de
Diagramme d’activité
Une classe
communication
communication
[2..*]
tableau
dynamique
sensDeFlux
Diagramme d’états
facultatif = in, out ou inout
Diagramme de
Diagramme de
Autres diagrammes
d'au moins 2 éléments
séquence
séquence
mais impératif
Diagramme d’activité
Diagramme d’activité
Démarche de
Une
classe
pour
l'implémentation
Diagramme d’états
Diagramme d’états
conception OO
plus ou moins de détails en fonction des besoins : Possibilité d’omettre
attributs et/ou opérations
Autres diagrammes
Une classe
Autres diagrammes
Démarche de
conception OO
I. BOUSSAID (USTHB)
Démarche de
conception OO
GL - COO
18 novembre 2013
35 / 101
Diagramme de classes
Classes et instances
Représentation UML des attributs
Représentation des attributs :
Représentation d’un attribut :
visibilité nom : type [multiplicité] = valeur initiale {p
public +
privé protégé #
facultatif
mais impératif
pour l'implémentation
I. BOUSSAID (USTHB)
facultatif
facultatif
par défaut: 1
[0..1] élément pouvant être nul
[4] tableau de 4 éléments
[2..*] tableau dynamique
d'au moins 2 éléments
GL - COO
18 novembre 2013
36 / 101
Diagramme de classes
Classes et instances
Une
opération
une fonction ou une procédure qui
Attributs
etest
Opérations
être appliquée aux objets ou par les objets d!une clas
LaReprésentation
même opération
peut
d’une opération
: s!appliquer à de nombreuse
classes
différentes.
Dans
ce cas,
on dit qu!elle
est
Une opération
représente
un élément
de comportement
(un service)
polymorphe
. une classe.
contenu dans
ajouterons
surtout
les opérations en conception
car cela po
Une Nous
méthode
est
l!implémentation
d!uneobjet,
opération
fait partie donnée.
des choix d’attribution des responsabilités aux objets.
une classe
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
37 / 101
Diagramme de classes
Classes et instances
Représentation UML des opérations
Format de description d’une opération :
[Visibilité] Nom ["(" Arg ")"] [" :" Type]
Visibilité : + (public), - (privé), # (protégé)
Arg : liste des arguments selon le format [Dir] NomArgument :
TypeArgument où Dir = in (par défaut), out, ou inout
Type : type de la valeur retournée (type primitif ou classe)
Opérations abstraites (non implémentées) en italique
Opérations de classe (statiques) soulignées
Possibilité d’annoter avec des contraintes stéréotypées «precondition»
et «postcondition» ; Programmation par contrats
Possibilité de surcharger une opération : même nom, mais
paramètres différents
Stéréotypes d’opérations : «create» et «destroy»
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
38 / 101
Diagramme de classes
Relations entre classes
Les associations
Diagramme de classes
Connexion sémantique bidirectionnelle entre classes
Relations entre classes
Représentation des associations :
Nom : forme verbale, avec un sens de lecture
Rôles : forme nominale, décrit une extrémité de l’association
Multiplicité
1, 0..1, 0..∗, 1..∗, n..m
Représentation
des: associations
I
Classe 1
x..y
nom association ▶
rôle 1
x..y
rôle 2
{mots-clés}
C
Classe 2
D
• Nom : forme verbale, avec un sens de lecture
• Rôles : forme nominale, décrit une extrémité de
l’association
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
39 / 101
Diagramme de classes
Relations entre classes
Les
associations
Représentation
des associations
I
Classe 1
x..y
nom association ▶
rôle 1
x..y
rôle 2
{mots-clés}
C
Classe 2
D
Interprétation en français :
• Nom : forme verbale, avec un sens de lecture
Un Classe1 nom association un Classe2 (ou un Classe2 nom association
un Classe1
sens de lecture
inverse)
• Rôles
: formesi nominale,
décrit
une extrémité de
Un Classe1 est rôle1 d’un Classe2 et mult1 (x..y) Classe1 peuvent jouer
l’association
ce rôle pour un Classe2
• Multiplicité
1,rôle2
0..1,d’un
0..*,
1..*,etn..m
Un Classe2 :est
Classe1
mult2 (x..y) Classe2 peuvent jouer
ce rôle pour un Classe1
D
c
• Mots clés : set, ordered set, list
Exemple :
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
40 / 101
Diagramme de classes
Relations entre classes
Les associations
Représentation des associations
I
Classe 1
x..y
nom association ▶
rôle 1
x..y
rôle 2
{mots-clés}
C
Classe 2
D
en langage de programmation orienté objet
• Interprétation
Nom : forme
verbale, avec un sens de lecture
La classe Classe1 a un attribut de nom rôle2
• Rôles
: forme
décrit
extrémité
de sinon
→ Type
= C2nominale,
si mult2 ∈ {1,
0..1},une
ou collection
de Classe2
La classe Classe2 a un attribut de nom rôle1
l’association
→ Type = C1 si mult1 ∈ {1, 0..1}, ou collection de Classe1 sinon
• Multiplicité : 1, 0..1, 0..*, 1..*, n..m
Exemple :
D
c
• Mots clés : set, ordered set, list
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
41 / 101
Diagramme de classes
Relations entre classes
Multiplicité des associations
:07 14
La multiplicité spécifie le nombre d’instances d’une classe pouvant être
liées à une seule instance d’une classe associée. Elle contraint le
nombre d’objets liés.
Exemple : une personne peut posséder plusieurs voitures (entre zéro
et un nombre quelconque) ; une voiture est possédée par une seule
personne.
ation
OSITION
I. BOUSSAID
(USTHB)
GL - COO
18 novembre 2013
42 / 101
Diagramme de classes
Relations entre classes
d’une association peut porter une indication de multiplicité qui
Multiplicité des associations
objets de la classe considérée peuvent être liés à un objet de
multiplicité est une information portée par l’extrémité
la forme d’une expression entière.
1
Un et un seul
0..1
Zéro ou un
N
N (entier naturel)
M .. N
De M à N (entiers naturels)
*
De zéro à plusieurs
0 .. *
De zéro à plusieurs
1 .. *
D'un à plusieurs
rend compte du fait que plusieurs personnes travaillent pour
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
43 / 101
Diagramme de classes
Relations entre classes
Multiplicité des associations
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
44 / 101
Multiplicité
Diagramme de classes
Relations entre classes
Multiplicité des associations
!
La multiplicité spécifie le nombre d!instances d!une
classe pouvant être liées à une seule instance d!une
Exemple :
classe associée. Elle contraint le nombre d!objets liés
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
45 / 101
Diagramme de classes
Relations entre classes
Multiplicité des associations
Exemple :
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
46 / 101
Diagramme de classes
Relations entre classes
Association Reflexive
Exemple de diagramme d’objets :
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
47 / 101
Diagramme de classes
Relations entre classes
Association multiple
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
48 / 101
Diagramme de classes
Relations entre classes
Relations entre classes
Exemple récapitulatif
Exemple
Entreprise
0..*
◀ travaille pour
employeur
1..*
employé
emploie ▶
Personne
patron
0..1
*
dirige ▼
employés
Association
réflexive
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
49 / 101
s
Diagramme de classes
Relations entre classes
• Directionnalité des associations
Navigabilité
d’une association
• bidirectionnelles
par défaut
• la navigation peut être restreinte à une seule
Par défaut, les associations sont navigables dans les deux directions.
direction
la navigation
peut être restreinte
à une restreinte)
seule direction : les instances
(association
à navigabilité
d’une classe ne "connaissent" pas les instances d’une autre.
Exemple
On restreint la navigabilité d’une association à un seul sens à l’aide
d’une flèche.
Citoyen
*
vote pour ▶
0..1
Candidat
ces trois notations ont la même sémantique
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
50 / 101
Diagramme de classes
Relations entre classes
Navigabilité d’une association
Qu’est-ce que la navigabilité d’une association entre C1 et C2 ?
Capacité d’une instance de C1 (resp. C2) à accéder aux instances de
C2 (resp. C1)
Par défaut : Navigabilité dans les deux sens : C1 a un attribut de
type C2 et C2 a un attribut de type C1
Spécification de la navigabilité : Orientation de l’association : C1 a
un attribut du type de C2, mais pas l’inverse
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
51 / 101
Diagramme de classes
Relations entre classes
Classe d’Association
Classe Attribuée
Une classe association peut participer à d’autres associations :
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
52 / 101
Classe-association
Diagramme de classes
Relations entre classes
Classe d’Association
!
Une classe-association est une
Une classe-association
est une
association
qui une
est aussi classe.
une classe.
association
qui
est
aussi
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
53 / 101
Diagramme de classes
Relations entre classes
Classe d’Association
Ne placez pas les attributs d’une association dans une classe.
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
54 / 101
Diagramme de classes
Relations entre classes
Classe d’Association
Exemple de diagramme d’objets :
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
55 / 101
Diagramme de classes
Relations entre classes
Classe d’Association
Équivalences
Parfois, l’information véhiculée par une classe-association peut être
véhiculée sans perte d’une autre manière
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
56 / 101
Diagramme de classes
Relations entre classes
Association n-aire
En général, les associations sont binaires
N-aires : au moins trois instances impliquées
Associations n-aires
A n’utiliser que lorsqu’aucune autre solution n’est possible !
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
57 / 101
Diagramme de classes
Relations entre classes
Association n-aire
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
58 / 101
Diagramme de classes
Relations entre classes
Association n-aire
Un cours ne peut exister que s’il existe un lien entre un objet
Enseignant et un objet Groupe. Quand le lien est rompu (effacé), le
cours l’est également.
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
59 / 101
Diagramme de classes
Relations entre classes
Si un cours doit pouvoir exister indépendamment d’un lien entre un
enseignant et un groupe, il faut utiliser une association ternaire.
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
60 / 101
Diagramme de classes
Relations entre classes
Dépendance
Une classe A dépend d’une classe B (noté A - - - - - - - - > B) si : Il existe
une association navigable de A vers B (ou A possède un attribut de type B)
Une méthode de A a un paramètre ou une var. locale de type B
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
61 / 101
Diagramme de classes
Relations entre classes
Agrégation
osite entraîne la destruction de tous ses éléments
Une agrégation est un cas particulier d’association non symétrique
cycleexprimant
de vieunedes
parties).
relation
de contenance d’un élément dans un
ensemble.
Les agrégations n’ont pas besoin d’être nommées : implicitement elles
signifient « contient », « est composé de ».
On représente l’agrégation par l’ajout d’un losange vide du côté de
l’agrégat (l’ensemble).
Agregat
Element
1..*
Composite
I. BOUSSAID (USTHB)
0..*
GL - COO
Element
18 novembre 2013
62 / 101
Diagramme de classes
Relations entre classes
Agrégation - Exemples
Une pièce est composée de murs. Un mur peut être commun à plusieurs
pièces
Agrégation
!
L!agrégation est une forme d!association forte dans
laquelle un objet agrégat est constitué de constituants
agrégés. Elle est transitive et antisymétrique.
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
63 / 101
u cycle de vie des parties).
Diagramme de classes
Relations entre classes
composition
Relation transitive et antisymétrique
Une composition est une agrégation plus forte impliquant que :
un élément ne peut appartenir qu’à un seul agrégat composite
(agrégation non partagée) ;
la destruction de l’agrégat composite (l’ensemble) entraîne la
Agregat
Element
destruction de tous ses éléments (les parties)
le composite est
responsable du cycle de vie 0..*
des parties.
1..*
Composite
Element
1
I. BOUSSAID (USTHB)
0..*
GL - COO
18 novembre 2013
64 / 101
Diagramme de classes
Relations entre classes
Composition - Exemples
Une partie constituante ne peut appartenir à plus d’un assemblage ;
Composition
une fois une partie constituante affectée à un assemblage, sa durée de
vie coïncide avec ce dernier.
!
Forme d!agrégation qui implique :
!
!
qu!une partie constituante ne peut appartenir à plus d!un
assemblage ;
une fois une partie constituante affectée à un assemblage, sa
durée de vie coïncide avec ce dernier.
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
65 / 101
Diagramme de classes
Relations entre classes
Composition - Exemples
Un mur est composé de briques. Une brique n’appartient qu’à un mur
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
66 / 101
Diagramme de classes
Relations entre classes
Agrégation vs. composition
Quand mettre une composition plutôt qu’une agrégation ?
Pour décider de mettre une composition plutôt qu’une
agrégation, on doit se poser les questions suivantes :
Est-ce que la destruction de l’objet composite (du tout) implique
nécessairement la destruction des objets composants (les parties) ?
C’est le cas si les composants n’ont pas d’autonomie vis-à-vis des
composites.
Lorsque l’on copie le composite, doit-on aussi copier les composants,
ou est-ce qu’on peut les «réutiliser», auquel cas un composant peut
faire partie de plusieurs composites ?
Si on répond par l’affirmative à ces deux questions, on doit utiliser une
composition.
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
67 / 101
Diagramme de classes
Relations entre classes
Propagation (ou déclenchement)
Application automatique d’une opération à un réseau d’objets à partir
d’un objet initial quelconque.
Propagation
l’agrégation permet un mécanisme de délégation d’opérations :
(ou déclenchement)
l’opération Document.copier() peut être déléguée à l’opération
Paragraphe.copier() en l’appliquant à toutes les instances de
! Application
automatique
d!une opération
à unà son
réseau
paragraphe
qui composent
le document.
Celle-ci peut
tour être
d!objets
à
partir
d!un
objet
initial
quelconque.
déléguée dans les mêmes conditions à Caractère.copier().
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
68 / 101
Diagramme de classes
Relations entre classes
Qualification
Association Qualifiée :
Un qualicatid d’association est une liste d’attributs dans une
association binaire où les valeurs des attributs sélectionnent un ou
plusieurs objets liés.
Un qualificatif agit toujours sur une association dont la multiplicité est
plusieurs
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
69 / 101
Diagramme de classes
Relations entre classes
Contraintes
UML permet d’associer une contrainte à un élément de modèle de
plusieurs façons.
Sur les deux diagrammes suivants, la contrainte porte sur un attribut
qui doit être positif.
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
70 / 101
Diagramme de classes
Relations entre classes
Contraintes
La contrainte frozen signifie que l’association, la classe ou l’attribut,
une fois créé ne changera jamais (ici frozen précise que le nombre de
roues d’un véhicule ne peut pas varier).
La contrainte subset précise que le président est également un membre
du comité.
La contrainte xor (ou exclusif) précise que les employés de l’hôtel
n’ont pas le droit de prendre une chambre dans ce même hôtel.
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
71 / 101
Diagramme de classes
Relations entre classes
Contraintes
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
72 / 101
Diagramme de classes
Relations entre classes
Contraintes
Le NAS d’un employé, une fois créé, ne peut changer
Read only signifie que la valeur peut changer à l’intérieur de la classe
mais ne peut être changée de l’extérieur de la classe (Le salaire, ne
peut être modifié à l’extérieur de la classe Employe)
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
73 / 101
Relations entre classes
Généralisation/Spécialisation
Diagramme de classes
Héritage (Généralisation/Spécialisation)
L’héritage une relation de spécialisation/généralisation.
tationLes: éléments spécialisés héritent de la structure et du comportement
des éléments plus généraux (attributs et opérations)
Classe B
Super-classe:
plus générale
Sous-classe:
plus spécialisée
Classe A
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
74 / 101
Diagramme de classes
Relations entre classes
Héritage
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
75 / 101
Diagramme de classes
Relations entre classes
Héritage
Pour que ça fonctionne :
Principe de substitution : toutes les propriétés de la classe parent
doivent être valables pour les classes enfant
principe du « A est un B » ou « A est une sorte de B » : toutes les
instances de la sous-classe sont aussi instances de la super-classe. Par
exemple, toute opération acceptant un objet d’une classe Animal doit
accepter tout objet de la classe Chat (l’inverse n’est pas toujours vrai).
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
76 / 101
Diagramme de classes
Relations entre classes
senter ?
Héritage
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
77 / 101
Diagramme de classes
Relations entre classes
pécialisation
Héritage
• Extension cohérente de classes
Relation transitive, non réflexive, et non symétrique !
elation
non-réflexive, non-symétrique !
Classe A
Classe A
Impossible !
I. BOUSSAID (USTHB)
Classe B
GL - COO
18 novembre 2013
78 / 101
Diagramme de classes
Relations entre classes
Héritage - Exemple
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
79 / 101
Diagramme de classes
Relations entre classes
Héritage Multiple
Une classe peut avoir plusieurs classes parents. On parle alors
d’héritage multiple.
Exemple :
Le langage C++ est un des langages objet permettant son
implantation effective.
Java ne le permet pas.
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
80 / 101
Diagramme de classes
Diagramme de classes
Héritage Multiple
Relations entre classes
Généralisation/Spécialisation
Comment
multiple
Commentéviter
éviter l’héritage
l’héritage multiple
??
Première
solution :solution
déléguer: déléguer
• Première
Classe A
Classe A
Classe B
Classe C
I. BOUSSAID (USTHB)
Classe B
Classe C
GL - COO
18 novembre 2013
81 / 101
i
e
L
Diagramme de classes
Relations entre classes
Diagramme de classes
Héritage Multiple
Généralisation/Spécialisation
Comment
éviterl’héritage
l’héritage multiple
??
Comment
éviter
multiple
• Deuxième
la importante
classe la plus
Deuxième
solution : solution
hériter de :lahériter
classe lade
plus
et déléguer les
autres importante et déléguer les autres
L
ses
Classe A
Classe A
Classe B
Classe B
s
té
Classe C
I. BOUSSAID (USTHB)
Classe C
GL - COO
18 novembre 2013
82 / 101
Diagramme de classes
Relations entre classes
Énumerations
Enumération
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
83 / 101
Diagramme de classes
objet élémentaire avec UML
Classes Modélisation
abstraites
Classes abstraites
Compléments sur la modélisation des classes
Diagrammes de classes
Une méthode est dite abstraite lorsqu’on connaît son entête
Une méthode
lorsqu'on
sonréalisée.
entête mais
(signature)
maisest
pasdite
la abstraite
manière dont
elle connaît
peut être
la manière dont elle peut être réalisée.
pas
Il appartient aux classes enfant de définir les methodes abstraites.
Il appartient aux classes enfant de dénir les methodes abstraites.
Une classe est dite abstraite lorsqu’elle définit au moins une
méthode
abstraite
lorsqu’une
classe parent
contient
uneméthode
méthode
Une classe
est diteouabstraite
lorsqu'elle
dénit au
moins une
abstraitenon
ou encore
lorsqu'une
classe parent contient une méthode abstraite
abstraite
réalisée.
non encore réalisée.
Pierre Gérard (P13 IUT Villetaneuse)
I. BOUSSAID (USTHB)
Introduction à UML 2
GL - COO
DUT Informatique S2D
66 / 342
18 novembre 2013
84 / 101
Diagramme de classes
Compléments sur la modélisation des classes
Classes Abstraites
Classes
abstraites - Exemple
Exemple :
classe
abstraite
FormeGéométrique
- couleur: string
opération
abstraite
+ calculeSurface()
+ type()
+ colorier(string)
s
é
Rectangle
- longueur
- largeur
+ calculeSurface()
+ type()
Cercle
- rayon
+ calculeSurface()
+ type()
return
PI x rayon²
return
longueur x largeur
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
85 / 101
Diagramme de classes
Compléments sur la modélisation des classes
Les interfaces
Le rôle d’une interface est de regrouper un ensemble d’opérations
assurant un service cohérent offert par une classe.
Une interface est définie comme une classe, avec les mêmes
compartiments. Les principales différences sont :
la non-utilisation du mot-clé "abstract", car l’interface et toutes ses
méthodes sont, par définition, abstraites ;
l’ajout du stéréotype "interface" avant le nom de l’interface.
Toutes les classes implémentant une interface doivent implémenter
toutes les opérations décrites dans l’interface
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
86 / 101
Diagramme de classes
UML
Compléments sur la modélisation des classes
• elles doivent mettre en œuvre les opérations de
à UML
e cas
l’interface
Les interfaces
e classes
e
’objets
e
n
e
’activité
’états
mmes
e
OO
«interface»
Interface 1
Représentation
synthétique
Interface 1
+ opération1()
+ opération2()
. . .
Représentation
détaillée
Exemple :
de
ion
Objet
Diagramme de classes
owski
Généralisation/Spécialisation
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
87 / 101
Diagramme de classes
Compléments sur la modélisation des classes
Classe Cliente de l’interface
Quand une classe dépend d’une interface (interface requise) pour
réaliser ses opérations, elle est dite "classe cliente de l’interface".
Graphiquement, cela est représenté par une relation de dépendance
entre la classe et l’interface. Une notation lollipop équivalente est
aussi possible.
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
88 / 101
Diagramme de classes
Compléments sur la modélisation des classes
Les interfaces : implémentation et utilisation
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
89 / 101
Diagramme de classes
Compléments sur la modélisation des classes
Attributs dérivés
Les attributs dérivés peuvent être calculés à partir d’autres attributs et
des formules de calcul.
Les attributs dérivés sont symbolisés par l’ajout d’un "/" devant leur
nom.
Lors de la conception, un attribut dérivé peut être utilisé comme
marqueur jusqu’à ce que vous puissiez déterminer les règles à lui
appliquer.
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
90 / 101
Diagramme de classes
Compléments sur la modélisation des classes
Attributs de classe
Par défaut, les valeurs des attributs définis dans une classe di fèrent
d’un objet à un autre. Parfois, il est nécessaire de dé finir un attribut
de classe qui garde une valeur unique et partagée par toutes les
instances.
Graphiquement, un attribut de classe est souligné
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
91 / 101
Diagramme de classes
Compléments sur la modélisation des classes
Opérations de classe
Semblable aux attributs de classe
Une opération de classe est une propriété de la classe, et non de ses
instances.
Elle n’a pas accès aux attributs des objets de la classe.
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
92 / 101
Diagramme de classes
Compléments sur la modélisation des classes
Diagrammes de classes à différents niveaux
On peut utiliser les diagrammes de classes pour représenter un
système à différents niveaux d’abstraction :
Le point de vue spécification met l’accent sur les interfaces des classes
plutôt que sur leurs contenus.
Le point de vue conceptuel capture les concepts du domaine et les
liens qui les lient. Il s’intéresse peu ou prou à la manière éventuelle
d’implémenter ces concepts et relations et aux langages
d’implémentation.
Le point de vue implémentation, le plus courant, détaille le contenu
et l’implémentation de chaque classe.
Les diagrammes de classes s’étoffent à mesure qu’on va de hauts
niveaux à de bas niveaux d’abstraction (de la spécification vers
l’implémentation)
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
93 / 101
Diagramme de classes
Compléments sur la modélisation des classes
Élaboration d’un diagramme de classes
Démarche
Trouver les classes du domaine étudié.
généralement des concepts ou des substantifs du domaine.
Trouver les associations entre classes.
Souvent des verbes, ou des constructions verbales, mettant en
relation plusieurs classes.
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
94 / 101
Diagramme de classes
Compléments sur la modélisation des classes
Élaboration d’un diagramme de classes
Démarche
Trouver les attributs des classes.
Souvent des substantifs, correspondant à un niveau de granularité plus
fin que les classes.
Les adjectifs et les valeurs correspondent souvent à des valeurs
d’attributs.
Organiser et simplifier le modèle en éliminant les classes
redondantes et en utilisant l’héritage.
Tester les chemins d’accès aux classées
Itérer et raffiner le modèle. Un modèle est rarement correct dès sa
première construction. La modélisation objet est un processus non pas
linéaire mais itératif.
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
95 / 101
Diagramme de packages
Plan
1
Introduction
Qualité d’une conception
Démarche fonctionnelle
Démarche orientée objet
2
Diagramme de classes
Classes et instances
Relations entre classes
Compléments sur la modélisation des classes
3
Diagramme de packages
4
Références
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
96 / 101
Diagramme de packages
Packages
Qu’est-ce qu’un paquetage (package) ?
Élément de modélisation qui :
Permet de grouper d’autres éléments de modélisation (classes, autres
paquetages, ...)
Sert d’espace de désignation
Peut inclure d’autres package
Peut importer d’autres package
L’héritage entre package est possible
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
97 / 101
Diagramme de packages
Diagramme de Packages
Notation
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
98 / 101
Diagramme de packages
Diagramme de Packages
Exemple
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
99 / 101
Diagramme de packages
Packages
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
100 / 101
Références
Plan
1
Introduction
Qualité d’une conception
Démarche fonctionnelle
Démarche orientée objet
2
Diagramme de classes
Classes et instances
Relations entre classes
Compléments sur la modélisation des classes
3
Diagramme de packages
4
Références
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
101 / 101
Références
Michael Blaha et James Rumbaugh Modélisation et conception
orientées objet avec UML2,
Christine Solnon Modélisation UML,
Pierre Gérard Génie Logiciel - Principes et Techniques,
A. Lewandowski Méthode de Conception Orientée Objet
Des figures et des transparents empruntés à Delphine Longuet et
Laurent AUDIBERT
I. BOUSSAID (USTHB)
GL - COO
18 novembre 2013
101 / 101
Téléchargement
Explore flashcards