Chapitre 3 : UML & Approche objet A.U.

: 2009/2010
ENSI – II2

a- Historique

Organisation du développement :
• Méthodes fonctionnelles et Systémiques
• SASD, SART, Jackson, …. / Années 60 → 90
• Apparitions de méthodes objets : 90
• Booch, OMT (Rumbaugh), OOSE (Jacobson)

Notation U.M.L Insuffisances

• Méthodes partielles, cantonnées à des domaines distincts
et approche objet • La variété des méthodes
difficulté de communication

La nécessité d’un effort de standardisation

Chap.3 : UML 2

b- L’évolution d'UML c- Présentation

UML 2.1

UML 1.4  UML est un ensemble de notations orientées objet

Standardisation par l'OMG -JUIN 99 UML 1.3  indépendant des langages particuliers de programmation,
Standardisation par l'OMG -NOV 97 UML 1.1  ouvert à des éventuelles concepts de réalisation
Soumission à l'OMG- janvier 97 UML 1.0  La syntaxe et la sémantique de UML sont précisément définies,
Version bêta OOPSLA'96
 Il permet de modéliser tout type de système et peut être utilisé à
WWW juin 96 UML 0.9 toute étape d’un cycle de vie de développement d’un système,
OOPSLA'95 Méthode unifiée 0.8 Jeu de documentation  UML est un langage de modélisation objet et non une méthode
(octobre 95)

Commentaires Booch'93 OMT-2

Autres méthodes Booch'91 OMT-1 OOSE Partenaires
Chap.3 : UML 3 Chap.3 : UML 4

Les quatre principes de

2- La Modélisation avec UML modélisation

Qu’est qu’un modèle? 1. Le choix des modèles à créer a une forte influence
Un modèle est une simplification de la réalité sur la manière d’aborder un problème et sur la
Pourquoi modéliser? nature de sa solution.
Les modèles permettent de mieux comprendre le système 2. Tous les modèles peuvent avoir différents niveaux
que l’on développe de précision.
3. Les meilleurs modèles ne perdent pas le sens de
Nous construisons des modèles pour les systèmes la réalité.
complexes parce que nous ne sommes pas en mesure 4. Parce qu’aucun modèle n’est suffisant à lui seul, il
d’appréhender de tels systèmes dans leur intégralité. est préférable de décomposer un système
important en un ensemble de petits modèles
presque indépendants.

Chap.3 : UML 5 Chap.3 : UML 6

1
Chapitre 3 : UML & Approche objet A.U. : 2009/2010
ENSI – II2

Intérêt du modèle Avantages et limites des modèles

 Le modèle est important pour : ☺ Un modèle est une vue subjective mais pertinente de la réalité
• Comprendre un problème ☺ Un modèle définit une frontière entre la réalité et la perspective de l'observateur
• Supporter un travail coopératif d'ingénierie  Ce n'est pas "la réalité", mais une vue très subjective de la réalité
• Prévoir et simuler la réalisation d'un développement
• Identifier et suivre les lots de travaux
• Guider, contrôler, automatiser la production

 Construire un bâtiment sans plan : Est ce possible?  mais pas d'autres.

 Permettant de poser
certaines questions …

 Et le logiciel?

Chap.3 : UML 7 Chap.3 : UML 8

Axes de modélisation d’un système

La Modélisation avec UML
Statique (ce que le système EST)

• diagramme de classes
 Chaque type de diagramme UML possède une structure (les types des
• diagramme d’objets éléments de modélisation qui le composent sont prédéfinis).

•…
 Un type de diagramme UML véhicule une sémantique précise (un type de
diagramme offre toujours la même vue d'un système).
Dynamique
(comment le système Fonctionnel  Combinés, les différents types de diagrammes UML offrent une vue
EVOLUE) (ce que le système FAIT) complète des aspects statiques et dynamiques d'un système.
• diagramme de collaboration
• diagramme de cas d’utilisation  Plusieurs vues pour un même type de diagramme
• diagramme d’états-transitions
•… •…

Chap.3 : UML 9 Chap.3 : UML 10

Un formalisme & plusieurs vues 3. Les concepts sous-jacent au

à l’analyse (modèle conceptuel)

 UML est basé sur différents concepts de base :

Algorithme du logiciel
Algorithme du monde réel
(scénario) (scénario) • Objet, Classe (concept du monde réel / TAD)
Objets du • Lien, Association
monde Objets du Objets du • Contrainte
réel logiciel langage • Héritage

De quoi parle-t-on ? Comment ‘logique’ ? Comment ‘physique’ ?  UML propose des notations et des diagrammes
• Diagramme de classes (description au niveau modélisation, cas général)
Analyse Conception Code • Diagramme d’objets (description au niveau instance, exemples)

Modèle conceptuel Modèle logique Modèle physique

Chap.3 : UML 11 Chap.3 : UML 12

2
Chapitre 3 : UML & Approche objet A.U. : 2009/2010
ENSI – II2

Notations de précision 3.1 Notation pour les classes

proposés par UML
Nom de la classe
 UML définit un petit nombre de mécanismes Compte
communs qui assurent l’intégrité de la notation: numéro : entier Attributs
• Stéréotypes: <<nom du stéréotype>> par ex. :<<Actor>>, solde : réel nom
<<send>> • C’est un moyen de classer les éléments du modèle découvertMax : entier type
• Le stéréotype s’applique principalement aux classes
• Il rend possible l’identification d’une typologie de Opérations
• Notes Note classes, souvent utile lorsque leur nombre est important consulterSolde() : entier nom
créditer( somme : entier) paramètre
débiter( somme : entier) type du résultat
• Contraintes : {contrainte} exprimées avec OCL

• Relations de dépendance entre 2 éléments: ---->

{ inv: solde > découvertMax } Contraintes

Par défaut, les attributs sont cachés et les opérations sont visibles

13 Chap.3 : UML 14

3.2 Notations pour les objets

Notations simplifiées
pour les classes
M0 leCompteDeAli leCompteDeAli : Compte
M1
Compte Compte numéro = 6688
numéro Compte
numéro : Compte solde = 5000
solde numéro découvertMax = -100
solde : réel
... solde
Compte découvertMax : entier
... leCompteDeAli : Compte
créditer() consulterSolde() : entier
Compte
débiter() créditer( somme : entier)
Compte créditer() ... débiter( somme )
débiter()
... Une collection d’objets peut être représentée : : Compte

Note de style : Convention :

• les noms de classes commencent par une majuscule • les noms d ’objets commencent par une minuscule et sont soulignés
• les noms d ’attributs et de méthodes commencent par une minuscule
Chap.3 : UML 15 Chap.3 : UML 16

Classe vs. Objets

Liens (entre objets)
Une classe spécifie la structure et le Un lien indique une connexion entre deux objets
comportement d'un ensemble d'objets
de même nature APourCompte
Compte
numéro
Ali : Client c1 : Compte
solde : réel
découvertMax : entier Diagramme
 La structure d'une classe est constante consulterSolde() : entier
de classes APourCompte
créditer( somme : entier)
débiter( somme ) Slim : Client c2 : Compte
M1
M0
leCompteDeSana:Compte leCompteDeAli : Compte
sana : Client c3 : Compte
 Des objets peuvent être numéro = 2275 numéro = 6688
ajoutés ou détruits pendant solde = 10000
découvertMax = -1000
solde = 5000
découvertMax = -100 Diagramme
l ’exécution d ’objets Note de style :
:Compte
 La valeur des attributs des • les noms des liens sont des formes verbales et commencent par une majuscule
objets peut changer numéro = 1200
solde = 150
• indique le sens de la lecture (ex: « ali APourCompte c1 »)
découvertMax = 10

Chap.3 : UML 17 Chap.3 : UML 18

3
Chapitre 3 : UML & Approche objet A.U. : 2009/2010
ENSI – II2

Contrainte sur les liens Contrainte sur les liens

 Au maximum un lien d'un type donné entre deux objets donnés*
 Au maximum un lien d'un type donné entre
deux objets donnés*
APourEpouse APourEpouse
Youssef : Personne APourEpouse Sondes : Personne Youssef : Personne APourEpouse Sondes : Personne

EstEnfantDe

EstGardePar
Souha : Personne Hédi : Personne
OK
EstEnfantDe

 Contrainte importante pour compendre les "classes associatives"

 (*) Contrainte pouvant être relachée via {nonunique} en UML 2.0
 ... voir plus loin les concepts avancés
Chap.3 : UML 19 Chap.3 : UML 20

Rôles 3 noms pour 1 concept

Chacun des deux objets joue un rôle diffèrent dans le lien utilisations différentes selon le contexte

APourCompte
R Salah : Client c1 : Compte
APourCompte a b titulaire compte
Salah : Client c1 : Compte g f
titulaire compte

•aRb • salah a pour compte c1

• b "joue le role de" f "pour" a • c1 joue le role de compte pour salah
• a "joue le role de" g "pour" b • salah joue le role de titulaire pour c1
Note de style :
• choisir un groupe nominal pour désigner un rôle
• si un nom de rôle est omis, le nom de la classe fait office de nom

Chap.3 : UML 21 Chap.3 : UML 22

3.3 Associations (entre classes) Association vs. Liens

association
Une association décrit un ensemble de liens de même "sémantique" classe APo u rCo m pte>

M1
Cl i e n t Co m p te

 Un lien lie deux objets

 Une association lie deux classes M0
Diagramme
APo u rCo m pte>

a l i : Cl i en t c 1 : Co mp te

APourCompte
Client Compte de classes objets s a l a h : Cl e
i nt
APo u rCo m pte>

c 2 : Co mp te

titulaire compte
(modélisation)  Un lien est une instance d’association s a n a : Cl i ent c 3 : Co mp te

M1  Une association décrit un ensemble de liens liens

M0
APourCompte>
Ali : Client c1 : Compte  Des liens peuvent être ajoutés ou détruits pendant l ’exécution,
(ce n ’est pas le cas des associations)
Diagramme
APourCompte>
Salah : Client c2 : Compte d ’objets
(exemplaires) Le terme "relation" ne fait pas partie du vocabulaire UML
Sana: Client c3 : Compte

Chap.3 : UML 23 Chap.3 : UML 24

4
Chapitre 3 : UML & Approche objet A.U. : 2009/2010
ENSI – II2

Nommer les associations Utiliser les rôles pour

«naviguer»
Compte Banque
APourCompte
Client Compte
titulaire comptes
Compte Banque M1
banqueGérante
Plusieures façons de M0 titulaire
APourCompte>

nommer une association ali.comptes = {c1}

ali : Client
comptes
c1 : Compte
Compte mais respecter la cohérence Banque
comptesGérés salah.comptes = {c2,c3}
entre identificateurs sana.comptes ={} salah : Client
titulaire APourCompte>
comptes
c2 : Compte

Gère c1.titulaire = ali titulaire

Compte Banque c2.titulaire = salah sana : Client c3 : Compte

comptes
c3.titulaire = salah

EstGéréPar
Compte Banque
comptesGérés banqueGérante Nommer en priorité les rôles
Chap.3 : UML 25 Chap.3 : UML 26

Cardinalités d’une 1..1 noté 1

0..1
: Un et un seul
: Zéro ou un
association 0..* noté *
1..*
: De Zéro à n
: De un à n
Exemple de lecture d’un diagramme
n..m : De n à m
Un box peut être loué par au
 Précise combien d’objets peuvent être liés à un seul objet source maximum
Un contratun seul contrat
concerne ou peut
la location d'un
 Cardinalité minimale et cardinalité maximale ( Cmin..Cmax) seul box rester non loué.
à la fois.
UnUn
boxvéhicule
peut être
estvide
autorisé
ou contenir
à aller au
dans
maximum
un box (au
2 véhicule.
minimum) ou plus.
1 APourCompte 0..*
Client Compte
titulaire comptes

« Un client a 0 ou plusieurs comptes » Un

Unlocataire peut
contrat ne souscrire
concerne plusieurs
qu'un seul
« Un compte a toujours 1 et 1 seul titulaire » contrat mais doit en avoir souscrit au
locataire.
M1
moins un.
M0 APourCompte>
ali : Client c1 : Compte
 Faites une description de ce diagramme de classe en explicitant en une
salah : Client
APourCompte>
c2 : Compte
phrase chacune des multiplicités :
Box –contrat – Box ; Box – Véhicule – Box ; Contrat – Locataire – Contrat
sana : Client c3 : Compte

Chap.3 : UML 27 Chap.3 : UML

Exercice de lecture d’un

diagramme de classes Diagrammes d’objets

EstAcceptéPar>
: Distributeur
: CarteBleue

Compte Banque
signataire

1..4 0..* 1..* 1..* fred : Client

titulaires
c4 : Compte : Banque : Consortium
Client numéro numéro
titulaires solde nom
1 signataire ... 0..* : CarteBleue
signataire

1 M0
Consortium ali : Client
titulaires
c1 : Compte : Banque

CarteBleue
0..* * 1 titulaires
salah : Client c2 : Compte
: Consortium
Code
retraitMax EstAcceptéPar> 0..*
Distributeur sana : Client
titulaires
c3 : Compte : Banque
1..*
signataire
: CarteBleue
EstAcceptéPar>
sophie : Client : Distributeur
EstAcceptéPar>

Chap.3 : UML 29 Chap.3 : UML 32

5
Chapitre 3 : UML & Approche objet A.U. : 2009/2010
ENSI – II2

Diagrammes de classes vs.

Diagrammes de classes vs. d’objets
d’objets
Co m p te
Ba n q u e
1 ..4 0 1 1
. . .

Compte
. . .
Cl i e n t * * *
n u m é ro

Banque
s olde
... n u m é ro
nom
ti tu l a i res

1..4 0..* 1..* 1..*

 Un diagramme de classes 1 s i g n a tai re

Co n s o rti um
0
.
.
*

Client numéro
numéro
titulaires
• solde
Ca rte Bl e ue

nom
défini l’ensemble de tous les états possibles
0 *
.
. 1
*

Co d e
re tra i tM ax
...
Es tAc c ep té Pa r> 0
.
.

1 signataire 0..*
•
Di s tri b u teur *

les contraintes doivent toujours être vérifiées

.
.
*

1
Consortium
CarteBleue
0..* * 1
 Un diagramme d’objets s
i
g
n
a
t ali :
a
Cl i ent
t
:
Ca rte
Bl e ue

c1 :
Co mp
te
:
B
Code

•
i i a
r t n
e u q

retraitMax
l u

EstAcceptéPar> 0..*
a e

décrit un état possible à un instant t, un cas particulier

ti
i r

M1
s al ah te c2 :
: :
us Co m
Co ns
Cl i ent l p te
o rti u
a m

Distributeur
i
r
e
ts
i
sana : t c3 : :
Cl i ent u Co mp
l te B
a a
s i n

•
i r q
e :

1..*
g Ca rte u
n s e
Bl e ue
a Es tA
t c cept
a é Par

doit être conforme au modèle de classes

s o phi i > :
e : r Distri
Cl i ent e b uteu
: r
Es tA Ca rte
c cept Bl e ue
é Par
> s
i
g
n
a
: c1 : ali : t
Co mp Cl i ent
B te t a
a i i
n t r

M0
q u e
u l
e a
i
rt
c2 : ei s al ah
: Co m st :
Co ns p te u Cl i ent
o rti u l
m a
i
r
e
ts
i
: c3 : t sana :
Co mp u Cl i ent
B te l
a a
n i > >
s
q r i : :
: e
u Ca rte g >
e s n
Bl e ue : :
a :
Es tA t
c cept
é Par a :
: i s o phi
Distri > e :
r
b uteu e Cl i ent
r Es tA

Les diagrammes d’objets peuvent être utilisés pour

c cept
é Par
> : Cl i e n t : : : Co n s o rti um : Cl i e n t : : : Co n s o rti um


: Cl i e n t : : : Co n s o rti um

: :

...
:

• expliquer un diagramme de classe (donner un exemple) : Cl i e n t

t
i
t
u
l
a
i
r
e
s
t
i
t
u
l
a
i
: Co m p te

: Co m p te
:
Ba nq
ue

: Co n s o rti um
: Cl i e n t
t
i
t
u
l
a
i
r
e
s
: Co m p te

: Co m p te
:
Ba nq
ue

: Co n s o rti um
t
i
t
u
l
a
i
r
e
s
: Co m p te

: Co m p te
:
Ba nq
ue

: Co n s o rti um

•
r
e
s

t t t

valider un diagramme de classe (le "tester")

i i i
: Cl i e n t t t : Co m p te : Cl i e n t t : Co m p te
u u : : u : t
l l Ba nq Ba nq l Ba nq i
a a ue ue a ue : Cl i e n t t : Co m p te
u :
i i i Ba nq
r r r l
a ue
e s ign e e
s a tai r s s i
e : : r
e
s
:
> >

: Cl i e n t : Di s tri b uteu r : Di s tri b uteu r : Cl i e n t : Di s tri b uteu r >

: Cl i e n t : Di s tri b uteu r
> >

>

t1 t2 t3
Chap.3 : UML 33 Chap.3 : UML 34

Rappel
3.4 Navigation

Algorithme Algorithme
Objets du du monde réel du logiciel
scénario) Objets du (scénario) Objets du Association unidirectionnelle
monde
logiciel langage On ne peut naviguer que dans un sens
réel

De quoi parle-t-on ? Comment ‘logique’ ? Comment ‘physique’ ?

UML2.0
Analyse Conception Code
titulaire
Client Compte
1 *

En cas de doute, ne pas mettre de flèche !!!

Son utilisation est surtout pour les modèles logiques et physiques
Modèle conceptuel Modèle logique Modèle physique
36
Chap.3 : UML 35

3.5 Cas particulier d’associations Agrégation

Agrégation/composition

 Relation asymétrique, transitive (Relation de subordination) Agrégation =

cas particulier d’association
 Une extrémité supporte la notion de responsabilité : + contraintes décrivant la notion d'appartenance... ?
• toute opération du responsable peut se propager aux éléments
contraints
* Point
Figure *
 Agrégat / agrégé : durée de vie des agrégés indépendante x
y
de l'agrégat

 Composite / composant : durée de vie des composants Appartenance faible =

 Partage possible du composant avec d’autres Agrégat/Eléments Agrégés
dépendante du composite / conteneur - on parle  Une instance agrégée peut exister sans son agrégat et inversement
d'embarquement
Utiliser avec précautions pendant l’analyse (ou ne pas utiliser...)
Chap.3 : UML 37 Chap.3 : UML 38

6
Chapitre 3 : UML & Approche objet A.U. : 2009/2010
ENSI – II2

Composition Composition

Notion intuitive de "composants" et de "composites" ("Conteneur") Contraintes liées à la composition :

1. Un objet composant ne peut être que dans 1 seul objet composite
2. Un objet composant n’existe pas sans son objet composite
3. Si un objet composite est détruit (copié), ses composants aussi
1 1
Pneu Pneu
4 4
Voiture Roue Voiture
1 Roue 1
Jante Jante
Remarque :
i. Agrégation avec relation d'appartenance forte et coïncidence des durées de vie
ii. Les composants peuvent être créés après le composite, mais après création ils ont
composition = la même durée de vie
cas particulier d’association iii. Les composants peuvent être enlevés avant la mort du composite
+ contraintes décrivant la notion de "composant"... Dépend de la situation modélisée !
(Ex: vente de voitures vs. casse)

Chap.3 : UML 39 Chap.3 : UML 40

Composition Composition

1 1..* 1..*
Contraintes liées à la composition : Chapitre Section
1. Un objet composant ne peut être que dans 1 seul objet composite Document
0..1
2. Un objet composant n’existe pas sans son objet composite 0..1
0..*
3. Si un objet composite est détruit, ses composants aussi Figure
M1
1..*

1..* 1..*
Section M0 : section
Chapitre
Document : chapitre
0..* : section Contrainte :
Figure
: figure le graphe d'objets
: document forme un arbre
: chapitre : section (ou une forêt)
0..1
: figure
Chap.3 : UML 41 Chap.3 : UML 42

Composition Composition

Point Cercle Point Cercle

3..* 1 3..* 1
Polygone x Polygone x
rayon rayon
y y
M1 M1

c1 : Cercle
M0 M0
: Polygone rayon = 5

: : : :
Point
x=0 Point
x=0 Point
x = 10 Point
x = 10
y = 10 y=0 y=0 y=0

Chap.3 : UML 43 Chap.3 : UML 44

7
Chapitre 3 : UML & Approche objet A.U. : 2009/2010
ENSI – II2

3.6 Classes associatives Classes associatives

employés sociétés
Pour associer des attributs et/ou des méthodes aux associations Personne Société
* 0..2
=> classes associatives

employés sociétés
Emploi
M1 salaire
Personne 0..2 Société
* augmenter()

M0 e1
salaire
salaire==1500
1500
Emploi
salaire xerox
Le salaire est une information correspondant
augmenter() e2 • ni à une personne,
employé
salaire = 5000
employé
• ni à une société,
Le nom de la classe correspond au nom de l’association Mark ST mais à un emploi (un couple personne-société).
(problème: il faut choisir entre forme nominale et forme verbale) e3
salaire = 1000
sana employé

Chap.3 : UML 45 Chap.3 : UML 46

Classes associatives
Classes associatives

RAPPEL: Pour une association donnée, un couple d'objets ne peut être employé sociétés
connectés que par un seul lien correspondant à cette association. Personne 0..2 Société
(sauf si l'association est décorée par {nonunique} en UML2.0) *
Emploi e1
Emploi>
salaire p1 s1
p1 Emploi> s1
Ci-dessus, une personne peut avoir deux emplois, mais pas dans la même société
Cette contrainte reste vraie dans le cas où l’association est décrite à partir
d ’une classe associative.
e1
: Emploi p1 s1
salaire = 1500 e2

employé 0..2 * société

p1 s1 Emploi
Personne Société
: Emploi
1 salaire 1
salaire = 700 Ci-dessus, une personne peut avoir deux emplois dans la même société
Chap.3 : UML 47 Chap.3 : UML 48

Classes associatives : traduction Classes associatives : traduction

rolea(s) roleb(s) employés sociétés

A carda cardb B Personne * 0..2 Société

C Emploi
Transformation
systèmatique
pour revenir aux
concepts de base

rolea c(s) c(s) roleb emplois emplois

A C B employé société
1 cardb carda 1 Personne Emploi Société
1 0..2 * 1

Il ne peut y avoir qu'un objet C entre un

objet A et un objet B donné Il ne peut y avoir qu'un Emploi entre une
Personne et une Société
Chap.3 : UML 49 Chap.3 : UML 50

8
Chapitre 3 : UML & Approche objet A.U. : 2009/2010
ENSI – II2

Exemple 1 Exemple 2 Participation

nbDeButs
joueurs matchs
Virement Virement Joueur Match
*
montant montant *
Ou ?
* * joueur match
* Participation *
compteDébité * compteDébité1 1 compteCrédité Joueur Match
1 participations nbDeButs participations 1
{non unique}
Compte * Compte
M1 compteCrédité Il ne peut y avoir qu'une Participation
entre Joueur et un Match

M0 v1 M0 p1
compteDébité compteCrédité Peut-on avoir plusieurs joueur match Un joueur peut il avoir
Situation virements entre deux Situation ali plusieurs participations à un
c1 c2 finale
possible ? comptes ? possible ? match donné ?
compteDébité compteCrédité joueur match
v2 p2
Chap.3 : UML 51 Chap.3 : UML 52

Exemple 3 Exemple 4
CarteGrise Veuvage Veuvage
dateDélivrance
date date
Personne
propriétaires voitures
Voiture
montantAssurance Ou ? montantAssurance
* {nonunique}
{non unique} * conjointLaisséVeuf
* 0..1
0..1
conjointLaisséVeuf 1 1 conjointDécédé
propriétaire CarteGrise voiture
* *
Personne Voiture Personne *
1 carteGrises dateDélivrance carteGrises 1 conjointsDécédés Personne

M0 cg1 M0 v1
propriétaires voitures conjointLaisséVeuf conjointsDécédés Peut on toucher deux
Situation ali la106 Situation ali sana fois l'assurance ?
possible ? possible ?
propriétaires voitures conjointLaisséVeuf conjointsDécédés
cg2 v2
Chap.3 : UML 53 Chap.3 : UML 54

Classes associatives Associations n-aires

Les classes associatives sont des associations mais aussi des classes.
Elles ont donc les mêmes propriétés et peuvent par exemple être liées par des
Généralisation des classes associatives binaires : Une association peut
associations. relier une, deux ou plusieurs classes

employé société

Personne 0..2 Société

*
Emploi
* salaire
FicheDePaye
augmenter()

Chap.3 : UML 55 Chap.3 : UML 56

9
Chapitre 3 : UML & Approche objet A.U. : 2009/2010
ENSI – II2

3.7 Associations qualifiées Exemple

Un qualifieur est un attribut (ou un ensemble d'attributs) dont la valeur sert à * membres * <<enumeration>>
Titre
déterminer l'ensemble des instances associées à une instance via une Personne
association. Association1901
Secretaire
titre:Titre President
* 0..1 Tresorier

Repertoire nom Fichier

0..1 membres
Anis

membres
"Pour un répertoire, à un nom donné on associe qu'un fichier sylvia
Tresorier
(ou 0 s'il existe aucun fichier de ce nom dans ce répertoire)." ass1
President ahmed
Correspond à la notion intuitive d'index absente ci-dessous
Secretaire Taha

President
Repertoire Fichier ass2
*
Chap.3 : UML 57 Chap.3 : UML 58

Cardinalité des Associations Qualifiées Attributs de l'association

Cas classique: cardinalité 0..1
Les attributs qualifieurs sont des attributs de l'association,
0..1 pas de la classe
Banque nc Compte
0..1
Cas plus rare: cardinalité * (pas de contrainte particulière exprimée) Repertoire nom Fichier
* 0..1

Banque titre Employe

* *
nom="a" f1
r1
Cas plus rare: cardinalité 1 (généralement c'est une erreur) nom="b"

nl : NumLigne r2 nom="f" f2
Echiquier Case r2
nc : NumCol 1 1
0 comme cardinalité minimale, sauf si le domaine de l'attribut qualifieur est fini et Exemple liens "hard" en Unix: un fichier peut correspondre à des noms
toutes les valeurs ont une image. différents dans des répertoires différents
Chap.3 : UML 59 Chap.3 : UML 60

Classes associatives : traduction

Synthèse sur les associations
Contient sens de
Repertoire nom Fichier lecture
0..1 Nom de rôle Nom d ’association
* Cardinalités

Transformation Les attributs du

systèmatique pour qualifieur sont des
revenir aux attributs de < AssociationX 0..*
roleA
concepts de base l'association ClasseA x : string ClasseB
Contient
nom
AssociationX
Composition
Repertoire Fichier attributZ Navigation
(ou agrégation )
* *
Un répertoire contient 0 ou 1
fichier pour un nom donné Classe associative

Chap.3 : UML 62 Chap.3 : UML 63

10
Chapitre 3 : UML & Approche objet A.U. : 2009/2010
ENSI – II2

3.8 Généralisation /Spécialisation

Règles de généralisation (…)
Une classe peut être la généralisation d’une ou plusieurs autres classes.
Ces classes sont alors des spécialisations de cette classe.  La généralisation ne porte ni nom particulier ni valeur de
multiplicité.
"Super classe"
 La généralisation est une relation non réflexive: une classe ne peut
Personne Cas général Compte pas dériver d’elle-même.
 La généralisation est une relation non symétrique: si une classe B
dérive d’une classe A, alors la classe A ne peut pas dériver de la
classe B.
"Sous classes"
Homme Femme Compte
Cas spécifique Epargne
 La généralisation est par contre une relation transitive: si C dérive
d’une classe B qui dérive elle-même d’une classe A, alors C dérive
Deux points de vue lié (en UML) : également de A.
• relation d'héritage
• relation de sous-typage
Chap.3 : UML 64 Chap.3 : UML 65

Relation d'héritage Relation d'héritage et

redéfinitions
Les sous-classes « héritent » des propriétés des super-classes
(attributs, méthodes, associations, contraintes)
Compte
Une opération peut être
"redéfinie" dans les sous-classes solde
Compte
créditer()
* Banque débiter()
solde
CompteEpargne
créditer() Permet d'associer des méthodes
solde * Banque CompteEpargne
débiter() {inv: solde > -5000} spécifiques à chaque pour réaliser
tauxIntérêt
une même opération
créditer()
créditer() débiter()
débiter() ajouterIntérêts ()

CompteEpargne calculIntérêts ()

tauxIntérêt {inv: solde > -5000 et

tauxIntérêt < 100}
ajouterIntérêts () {inv: tauxIntérêt < 100}

Chap.3 : UML 66 Chap.3 : UML 67

Relation de sous-typage, Vision Synthèse des concepts de base

ensembliste
Compte
 Classe  Association  Héritage
• attribut • rôle
• opération • cardinalité
• Agrég./Comp./Associative/Qualifiée
Compte
M1 Epargne
M1
M0
tout objet d’une sous-classe c3 M0 o1 o1
o3 o1

appartient également à la c4 o4
o2
o2 o3
super-classe ce1 o2
ce3 o5
c4 c2
ce2
c1  Objet  Lien  Inclusion
ensembliste
Compte CompteEpargne
Chap.3 : UML 68 Chap.3 : UML 69

11
Chapitre 3 : UML & Approche objet A.U. : 2009/2010
ENSI – II2

Rappel Comment ‘logique’ ? 4. Les concepts sous-jacent à la

Conception conception (modèle logique)

Algorithme Algorithme La phase de conception vise à :

Objets du du monde réel du logiciel  déterminer quels seront les composants du logiciel à développer,
scénario) Objets du (scénario) Objets du
monde  préciser les caractéristiques de ces composants,
logiciel langage
réel  concevoir les algorithmes permettant à ces composants d’effectuer
les activités dont ils sont responsables.
De quoi parle-t-on ? Comment ‘physique’ ?
Le résultat de la phase de conception consiste en un modèle
Analyse Code logique/physique du système, représenté par :
 des diagrammes de classes décrivant la structure statique,
 des diagrammes associés aux aspects dynamiques (à voir dans le cours
de génie logiciel !).

NB : Les classes qui doivent apparaître sur les diagrammes de classes se

déterminent sur la base du modèle conceptuel. Les classes peuvent
notamment correspondre à des concepts, des éléments de concepts, ou des
Modèle conceptuel Modèle logique Modèle physique composants logiciels auxiliaires nécessaires à la bonne marche du système.

Chap.3 : UML 70 Chap.3 : UML 71

Conception Objet 4.1 Conception détaillée des classes

Deux niveaux de conceptions :
- une étape logique: indépendante de l’environnement de réalisation:  Définir le type des attributs identifiés en analyse.
Raffinement des diagrammes structurelles

 Conception détaillée des classes: trouver la meilleure manière de concevoir les

structure logique,
• Type de base + composé
 Conception détaillée des associations (typage, portée, rémanence): • Structure
• • Enumération
•
•
assurer la gestion des liens
traiter les classes associatives
optimiser la navigation
?
 Délégation: dépendance des relations d’agrégation et de composition.  Spécifier les Structures de Données.
 Raffiner la généralisation/spécialisation (héritage simple ou multiple):
• propriétés structurelles  Spécifier les visibilités des attributs et méthodes + prise en
• Interface
compte des propriétés (changeable, readOnly, frozen)
• propriétés comportementales (substitution)
- une étape physique: liée à des particularités des langages de programmation ou de
l’environnement d’exécution  Spécifier les méthodes + celles spécifiques à l’implantation

 Montrer les dépendances + Classes spécifiques

Chap.3 : UML 72 Chap.3 : UML
⇑ 73

Structure Enumération

• Définition : Ensemble d’attributs pouvant être regroupé. • Définition : Ensemble de littéraux d’énumération, ordonné.

<<structure>> <<structure>> <<enumeration>> <<enumeration>>

Date Adresse Jour Titre
jour numRue Lundi Secretaire
mois rue Mardi President
années codePostal Mercredi Tresorier
ville Jeudi VicePresident
pays Vendredi Membre
 Utilisation Samedi  Utilisation
Dimanche

Société Association_ENSI

adrss: Adresse nom : String

dateDeCreation : Date jourDeReunion : Jour

Chap.3 : UML 74 Chap.3 : UML 75

12
Chapitre 3 : UML & Approche objet A.U. : 2009/2010
ENSI – II2

Exemple de SD pour Pile Encapsulation

Pile Pile
Pile
T : Integer[1..100] T : Integer[1..100]
empiler(Integer) Indice : Integer = 0 Indice : Integer= 101
depiler()
sommet() : Integer
vide() : booleen

Axiomes :
0..1 succ
∀ P ∈ Pile, ∀ x ∈ int,
Pile
• vide(nouvelle()) = vrai <<structure>>
• vide(empiler(P,x)) = faux
Element
• sommet(empiler(P,x)) = x Tete : Element
info : Integer
• depiler(empiler(P,x)) = P
Interfaces Implémentation
Chap.3 : UML 76 Chap.3 : UML 77

Visibilité des éléments Déclaration d'attributs

[/] [ visibilité ] nom [ : type ] [card ordre] [ = valeur-initiale ] [ { props... } ]
 Restreindre l'accès aux éléments d'un modèle
 Contrôler et éviter les dépendances entre classes (et paquetages)
age
exemples: +age
+ public visible à l’extérieur de la classe
/age
# protégé visible que dans la classe et ses sous-classes
- solde : Integer = 0
− privé visible dans la classe uniquement
# age : Integer [0..1]
~ package visible dans la package uniquement
# numsecu : Integer {frozen}
soulignement élément de classe
# motsClés : String [*] {addOnly}
nbPersonne : Integer
Remarques :
 Utile lors de la conception et de l'implémentation, pas avant !
-N'a pas de sens dans le modèle d’analyse-  Adapter le niveau de détail au niveau d'abstraction
 La sémantique exacte dépend du langage de programmation !  La non précision de visibilité privée

Chap.3 : UML 78 Chap.3 : UML

⇑ 79

Dépendances
Déclaration d'opérations
 Une relation de dépendance entre une classe C1 (source) et une
[ visibilité ] nom [ ( params ) ] [ : type ] [ { props... } ] classe C2 (Cible) indique qu’une modification de C2 peut avoir
params := [ in | out| inout ] nom [ : type] [ =defaut ] [{ props... } ] une influence sur le fonctionnement de C1.
getAge()
+ getAge() : Integer
- updateAge( in date : Date ) : Boolean  En général, une relation de dépendance résulte du fait qu’une classe C1 connaît
# getName() : String [0..1] l’existence d’une classe C2. A cet effet, UML propose plusieurs stéréotypes :
+getAge() : Integer {isQuery}
« call » : la source appelle une opération de la cible
+addProject() : { concurrency = sequential }
« create » : la source crée une instance de la cible

« permit » : le source est amie de la cible
+addProject() : { concurrency = concurrent }
« use » : la source a besoin de la cible pour être implémentée
+main( in args : String [*] {ordered} )
 Adapter le niveau de détail au niveau d'abstraction Remarques :
 La non précision de visibilité public Seules les dépendances non triviales sont précisées sur les diagrammes.

Chap.3 : UML 80 Chap.3 : UML 81

13
Chapitre 3 : UML & Approche objet A.U. : 2009/2010
ENSI – II2

Conception détaillée des classes : 4.2 Conception détaillée

classes spécifiques des associations +-#

 Classe emboîtée
• Déclarée dans la portée lexicale d’une
autre classe.

 Classe utilitaire

Les classes utilitaires: permettent de
regrouper des éléments dans un module
sans pour autant définir une classe
complète.

Les classes utilitaires ne peuvent être  Spécifier la gestion des associés
instanciées car elles ne sont pas des
types de données. (gestion des liens entre objets)
 Traiter les classes associatives
 Classe Paramétrée
• Modèle de classe
• Paramètres Formels génériques (types,  Optimiser la navigation
opérations…)

Chap.3 : UML 82 Chap.3 : UML

⇑ 83

(i) Contraintes de gestion de

4.2.1 Spécifier la gestion des liens l’association

Par exemple :
• { ordered } : les éléments de la collection sont ordonnés
>
:

> :

: Cl i e n t : : : Co n s o rti um

• { nonUnique } : répétitions possibles (UML2.0)

: Cl i e n t : : : Co n s o rti um

• { frozen } : fixé lors de la création de l ’objet, ne peut pas changer

: Co m p te :
Ba nq
t ue
i
: Co m p te : t
Ba nq u
ue l
t a
i i
t r
u e
l s
a
: Co m p te
i : Co n s o rti um
r
e
s

• { addOnly } : impossible de supprimer un élément

: Cl i e n t : Co m p te
: Co n s o rti um

t
i
t
: Cl i e n t u : Co m p te :
l Ba nq
t a ue
i i
t r
: Cl i e n t u : Co m p te : e
l Ba nq s
a ue :
i
r
e
s >
:

: Cl i e n t : Di s tri b uteu r

>

>
: Cl i e n t : Di s tri b uteu r

>

t t' lignes
Ligne
RelevéDeCompte
* Opération
Spécifier les contraintes de gestion {ordered,addOnly}
Spécifier les méthodes assurant la gestion des liens
Il est possible de définir de nouvelles contraintes
Préciser la portée
Exemple

85
Chap.3 : UML
⇑ 84 Chap.3 : UML 85

Rôle non unique : traduction Role unique : traduction

possible
rolea R bs rolea R bs
A carda B A carda {unique} * B
{nonunique} *

a rs rolea b a rs rolea b
A R B A R B
1 * carda 1 1 * carda 1

Entre un a et un b donné il n'y a qu'un r

86
Chap.3 : UML 86 Chap.3 : UML 87

14
Chapitre 3 : UML & Approche objet A.U. : 2009/2010
ENSI – II2

Role ordonné : traduction Rôle ordonné : traduction

générale par chainage
générale par index
rolea R bs rolea R bs
A carda {ordered} * B A B
carda {ordered} *

aOfFirstRb firstRb rolea b

a rs rolea b A R B
0..1 0..1 carda 1
A R B
1 * carda 1 prevb nextRb
ib : integer 0..1 0..1
RHasNextb
Pour tout a, tous les rs ont un indice ib
different et couvrant l'intervalle de 1 au
nombre de bs.
(si {unique} on a aussi
Entre un a et un b il n'y a qu'un r) 88 Chap.3 : UML 89

(ii) Spécifier les méthodes pour la

Rôle ordonné 1 - * :
gestion des liens
traduction par index
a R bs
0..1
R 0..1 0..1
R 0..*
A 1 {ordered} * B a b a b
M1 M1

M0 M0

set add remove exist

a bs getAll
B get setAll removeAll
A nb
1 * insert removeIdx
iRb : integer empty
Pour tout a, tous les bs ont un indice iRb Remarque :
i. Les méthodes (ajout/suppression) doivent préserver la cohérence des cardinalités
différent et couvrant l'intervalle de 1 au ii. Les méthodes de navigation doivent être cohérentes avec le sens de navigation
nombre de bs. iii. En cas de cardinalité > 1 possibilité de prévoir un attribut de type collection
(surtout à définir lors de l’implémentation !! )

Chap.3 : UML
⇑ 90 Chap.3 : UML 91

Spécifier la gestion des liens Exemple

 La gestion est définie par le concepteur

getAll
{design tip=ignore}
exist C C {design tip=ignore}

nb  Marquage standard UML * B - a : int {frozen}

* B
a
empty {design tip=default} ajouter(C)
f() f(float)
add g() : int …
g()
setAll
remove
removeAll pas envisagé
pas envisagé
removeIdx si {addOnly} D
si {frozen}
set envisagé
seulement
insert si {ordered}
get

Chap.3 : UML 92 Chap.3 : UML

⇑ 93

15
Chapitre 3 : UML & Approche objet A.U. : 2009/2010
ENSI – II2

4.2.2 Traiter les classes associatives :

(iii) Préciser la portée des associations Placement des attributs selon les valeurs de multiplicité

Pour les associations 1..1, les attributs de l’association peuvent être déplacés dans une
des classes qui participent à l’association

Pour les association 1 vers N, le déplacement est généralement possible vers la classe
du coté N.

La promotion de l’association au rang de classe pour augmenter la lisibilité ou en raison
de la présence de l’association vers d’autres classes.

promotion en classe de la relation
Etudiant -Travail, avec un attribut Note

attribut Mention qualifie un diplôme :
La portée visibilité des rôles il correspond à la conception de la
 +, -, # relation Diplôme - Etudiant,

attribut Numéro qualifie une
R chambre: il correspond à la conception
a b de la relation: Etudiant- Chambre.
-g +f

Chap.3 : UML 94 95

4.2.3 Optimiser la navigation

4.3 Délégation
dépendance des relations d’agrégation et de composition

ajouter un sens de navigation et/ou une contrainte d’appartenance

ajouter de nouvelles associations,

modifier/supprimer les anciennes associations
Horloge Horloge {frozen}
Exemple :
8 dames sur un échiquier placées de telle sorte qu’aucune ne peut attaquer une autre ? -hh: CC = 24
2
-mm: CC = 60
Echiquier nouvelle(int,int) CompteurCyclique
2..4 incrémenter() +nouvelle(int,int)
Echiquier -valeur : int = 0
testNoAttack() voisine consulter() : Int x Int x Int +incrémenter()
voisine
-max : int {frozen}
2..4 +consulter_hh() : int
testNoAttack() +nouveau(int)
+consulter_mm() : int
Case +incrémenter()
Case 0..1 +valeur() : int
Première occupée Voisine +raz()
successeur occupée
0..1

Dame 0..1 Dame 0..1

Chap.3 : UML 96 Chap.3 : UML

⇑ 97

4.4.1 Raffiner les hiérarchies de classes

4.4 Raffinement de l’héritage

Les hiérarchies de classes ou classifications permettent de gérer la

complexité en ordonnant les objets au sein d’arborescences de
 Raffiner les hiérarchies de classes classes d’abstraction croissante.
• La généralisation: il s’agit de prendre des classes
 Penser à la diversification des implémentations existantes (déjà mises en évidence) et de créer de nouvelles
classes qui regroupent leurs parties communes; il faut aller du
plus spécifique vers le plus général.
 Contrôler la substitution
• La spécialisation: il s’agit de sélectionner des classes
existantes (déjà identifiées) et d’en dériver de nouvelles
classes plus spécialisées, en spécifiant simplement les
différences.

Chap.3 : UML
⇑ 98 Chap.3 : UML 99

16
Chapitre 3 : UML & Approche objet A.U. : 2009/2010
ENSI – II2

Exemple
Règles de généralisation
Racine

Spécialisation
Généralisation

g()
A B

f() g() A B
g() h()
f() h()

La généralisation ne porte aucun nom particulier; elle signifie toujours: est un

ou est une sorte de. La généralisation ne concerne que les classes, elle
n’est pas instantiable en liens et, de fait, ne porte aucune indication de
multiplicité.

Chap.3 : UML 100 Chap.3 : UML 101

[PAM-00 p49]

Exemple 2 :
Spécialisation 4.4.2 Diversification des implémentations

Figure
couleur Le concept d’interface a été introduit dans UML pour modéliser des
position du centre
épaisseur du trait techniques de description de composants qu’on trouve sur le marché.
type de trait
déplacer
Une interface est la déclaration d’une collection d’opérations qui
sélectionner peuvent être utilisées pour définir un service. Une interface spécifie
pivoter
afficher des opérations visibles d’une classe sans en définir la structure
interne. Elle ne spécifie souvent qu’une partie limitée du
comportement d’une classe. Les interfaces n’ont ni implémentation,
Dimension 0 Dimension 1 Dimension 2 ni attributs, ni états, ni associations. Elles peuvent cependant
orientation orientation
type de remplissage disposer de relations de généralisation.
redimensionner redimensionner
remplir
Une interface est représentée par un petit cercle ayant un nom
Une classe Une interface
Point Ligne Arc Spline Polygones Cercles
angle
bornes nb cotés
angle départ Pts de contrôle diamètre
angle fin
sommets Représentation d’une interface au moyen d’un petit cercle
pivoter relié à la classe qui fournit effectivement les services
afficher afficher afficher afficher afficher
afficher
Chap.3 : UML
⇑ 102 Chap.3 : UML 103

Les interfaces
Réalisation
 Les interfaces La réalisation est une relation sémantique entre deux
• Pour montrer les opérations dans une interface, on la spécifie classificateurs, selon laquelle un des classificateurs décrit un
comme une classe avec le stéréotype «interface» contrat dont l’exécution est garantie par l’autre.

Exemple
«Interface»
«Interface»
Pile
Stockable
{abstraite}
{abstraite}

empiler() {abstraite}
depiler() {abstraite} charger() {abstraite}
sommet() {abstraite} sauver() {abstraite}
vide() {abstraite}

Chap.3 : UML 104 Chap.3 : UML 105

17
Chapitre 3 : UML & Approche objet A.U. : 2009/2010
ENSI – II2

Interface & Réalisation

Les interfaces
 Les interfaces  Les interfaces
• Les interfaces jouent un rôle important dans la construction de •Une interface peut être réalisée par plusieurs classes
systèmes
• Une interface décrit le comportement visible d’une classe, d’un •Une même classe peut réaliser plusieurs interfaces
composant, d’un sous-système ou d’un package Exemple
Crédit
• Le comportement visible d’une interface est décrit par des «utilise»
opérations abstraites dont la visibilité est publique Entreprise Banque La classe Banque
• Une interface est représentée par un petit cercle ayant un nom «utilise»
réalise les deux
interfaces Crédit et
Assurance
Une classe Une interface
«utilise»
Client «Interface»
Représentation d’une interface au moyen d’un petit cercle Assurance
relié à la classe qui fournit effectivement les services

Chap.3 : UML 106 Chap.3 : UML

⇑ 107

4.4.3 Substitution Les classes abstraites

 Si deux concepts sont liés par une relation de spécialisation,  Les classes abstraites ne sont pas instanciables directement,
alors toute instance du concept spécialisé doit pouvoir jouer le  Les classes abstraites forment une base pour les logiciels extensibles,
rôle d’une instance du concept général.  Les nouveaux besoins, les extensions et les améliorations sont
concentrées dans de nouvelles sous-classes,
 Il doit être possible de substituer une instance du concept spécialisé à une  Une classe est désignée comme abstraite au moyen de la propriété
instance du concept général dans toutes les applications où ce dernier booléenne Abstraite définie pour tous les éléments généralisables,
joue un rôle.
 La propriété Abstraite peut également être appliquée à une opération
A
f() Pile Figure
g() {abstraite} {abstraite}
centre : Point
empiler() {abstraite}
C translater()
B depiler() {abstraite}
sommet() {abstraite} surface() {abstraite}
h() vide() {abstraite}
f()

Chap.3 : UML 108 Chap.3 : UML 109

Exemple

Chap.3 : UML
⇑ 110

18