Vous êtes sur la page 1sur 12

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 Exercice n°2


diagramme de classes

Description d’un système de fichiers


Compte Banque
1..4 0..* 1..* 1..*
Client numéro numéro
titulaires solde  Un utilisateur possède au moins un répertoire
nom
1 signataire ... 0..*  Un répertoire appartient à un et un seul utilisateur
1
Consortium  Un répertoire peut contenir d ’autres répertoires
CarteBleue
0..* * 1  Un utilisateur peut accéder à au moins un répertoire
Code  Un répertoire peut être accédé par au moins un utilisateur
retraitMax EstAcceptéPar> 0..*
Distributeur
1..*

Chap.3 : UML 29

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

Diagrammes d’objets
Exercice n°2 (Solution)
EstAcceptéPar>
: Distributeur
: CarteBleue
signataire

Contenus titulaires
<Contient fred : Client c4 : Compte : Banque : Consortium

0..*
1..* : CarteBleue
1..1 Est propriétaire de>
signataire
Contenant M0
0..1 ali : Client c1 : Compte : Banque
Utilisateur Répertoire titulaires

1..* Peut accéder à> 1..* titulaires


salah : Client c2 : Compte
: Consortium
utilisateur autorisé
titulaires
sana : Client c3 : Compte : Banque

signataire
: CarteBleue
EstAcceptéPar>
sophie : Client : Distributeur
EstAcceptéPar>

Chap.3 : UML 32

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

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

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

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

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

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

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

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

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

Exemple 1 Exemple 2 Participation


nbDeButs
joueurs matchs
Virement Virement Joueur Match
*
montant montant *
Ou ?
* * joueur
* Participation * match
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 *
Personne Voiture
carteGrises dateDélivrance carteGrises 1 conjointsDécédés Personne
1

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

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

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

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

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

Classes associatives : traduction


Problème classique
Souvent l'index est également un attribut de classe indexée
Contient
Repertoire nom Fichier
Solution correcte: * 0..1

Repertoire nom Fichier Transformation Les attributs du


1 0..1 systèmatique pour qualifieur sont des
/nom revenir aux attributs de
Le nom du fichier correspond au nom qu'a concepts de base
le fichier dans le répertoire Contient l'association
nom

2 erreurs communes: Repertoire Fichier


* *
Repertoire nom Fichier
1 1 Un répertoire contient 0 ou 1
nom fichier pour un nom donné
Chap.3 : UML 61 Chap.3 : UML 62

3.8 Généralisation /Spécialisation


Synthèse sur les associations
sens de Une classe peut être la généralisation d’une ou plusieurs autres classes.
lecture Ces classes sont alors des spécialisations de cette classe.
Nom de rôle Nom d ’association
Cardinalités
"Super classe"
Personne Cas général Compte

roleA < AssociationX 0..*


ClasseA x : string ClasseB

AssociationX "Sous classes"


Composition Homme Femme Compte
attributZ Navigation Cas spécifique
(ou agrégation ) Epargne

Deux points de vue lié (en UML) :


• relation d'héritage
Classe associative • relation de sous-typage
Chap.3 : UML 63 Chap.3 : UML 64

Relation d'héritage
Règles de généralisation (…)
Les sous-classes « héritent » des propriétés des super-classes
 La généralisation ne porte ni nom particulier ni valeur de (attributs, méthodes, associations, contraintes)
multiplicité.
Compte
 La généralisation est une relation non réflexive: une classe ne peut *
solde Banque
pas dériver d’elle-même. CompteEpargne
créditer()
 La généralisation est une relation non symétrique: si une classe B débiter() {inv: solde > -5000}
solde * Banque
dérive d’une classe A, alors la classe A ne peut pas dériver de la tauxIntérêt
classe B. créditer()
débiter()
 La généralisation est par contre une relation transitive: si C dérive calculIntérêts ()
d’une classe B qui dérive elle-même d’une classe A, alors C dérive CompteEpargne
également de A. tauxIntérêt {inv: solde > -5000 et
tauxIntérêt < 100}
ajouterIntérêts () {inv: tauxIntérêt < 100}

Chap.3 : UML 65 Chap.3 : UML 66

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

Relation d'héritage et Relation de sous-typage, Vision


redéfinitions ensembliste
Compte
Compte
Une opération peut être
"redéfinie" dans les sous-classes solde
créditer()
débiter() Compte
Permet d'associer des méthodes M1 Epargne
CompteEpargne
spécifiques à chaque pour réaliser
une même opération M0
créditer() tout objet d’une sous-classe c3
débiter()
ajouterIntérêts () appartient également à la c4
super-classe ce1
ce3 c4 c2
ce2
c1
Compte CompteEpargne
Chap.3 : UML 67 Chap.3 : UML 68

Synthèse des concepts de base

 Classe  Association  Héritage


• attribut • rôle
• opération • cardinalité
• Agrég./Comp./Associative/Qualifiée

M1

M0 o1 o1
o3 o1

o2
o4
o2 o3
o2
o5

 Objet  Lien  Inclusion


ensembliste

Chap.3 : UML 69

12

Vous aimerez peut-être aussi