Analyse Structurelle

1- Introduction Générale
Données Espace de problème Résultats

Objets du
Algorithme du monde réel Objets de
monde (scénario)
réel l’application

Représentation du pb Interprétation humaine

par le programmeur des résultats

Concepts du
langage de Données
Algorithme informatique
programmation de sortie

Chap.3 : UML 2
 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)
Insuffisances
• Méthodes partielles, cantonnées à des domaines distincts
• La variété des méthodes
difficulté de communication

La nécessité d’un effort de standardisation

Chap.3 : UML 3
 Axes de modélisation d’un système

Statique (ce que le système EST)

• diagramme de classes
• diagramme d’objets
•…

Dynamique
(comment le système Fonctionnel
EVOLUE) (ce que le système FAIT)
• diagramme de collaboration
• diagramme d’états-transitions • diagramme de cas d’utilisation

•… •…

Chap.3 : UML 4
Un formalisme & plusieurs vues

Algorithme du monde réel Algorithme du logiciel

(scénario) (scénario)

Objets du
monde Objets du Objets du
réel logiciel langage

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

Analyse Conception Code
Modèle conceptuel Modèle logique Modèle physique

Chap.3 : UML 5
3.1 Notation pour les classes

Nom de la classe
Compte

numéro : entier Attributs

solde : réel nom
découvertMax : entier type

Opérations
consulterSolde() : entier nom
créditer( somme : entier) paramètre
débiter( somme : entier) type du résultat

{ inv: solde > découvertMax } Contraintes

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

Chap.3 : UML 6
 Notations simplifiées
pour les classes
M1
Compte Compte
numéro Compte
numéro
solde numéro
solde : réel
... solde
Compte découvertMax : entier
...
créditer() consulterSolde() : entier
Compte
débiter() créditer( somme : entier)
Compte créditer() ... débiter( somme )
débiter()
...

Note de style :
• les noms de classes commencent par une majuscule
• les noms d ’attributs et de méthodes commencent par une minuscule
Chap.3 : UML 7
 3.2 Notations pour les objets

M0 leCompteDeAli leCompteDeAli : Compte

numéro = 6688
: Compte solde = 5000
découvertMax = -100

leCompteDeAli : Compte

Une collection d’objets peut être représentée : : Compte

Convention :
• les noms d ’objets commencent par une minuscule et sont soulignés

Chap.3 : UML 8
 Classe vs. Objets

Une classe spécifie la structure et le

comportement d'un ensemble d'objets
de même nature
Compte
numéro
solde : réel
découvertMax : entier Diagramme
 La structure d'une classe est constante consulterSolde() : entier
de classes
créditer( somme : entier)
débiter( somme )

M1
M0
leCompteDeSana:Compte leCompteDeAli : 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
:Compte
 La valeur des attributs des
objets peut changer numéro = 1200
solde = 150
découvertMax = 10

Chap.3 : UML 9
 Liens (entre objets)
Un lien indique une connexion entre deux objets

APourCompte
Ali : Client c1 : Compte

APourCompte
Slim : Client c2 : Compte

sana : Client c3 : Compte

Note de style :
• les noms des liens sont des formes verbales et commencent par une majuscule
• indique le sens de la lecture (ex: « ali APourCompte c1 »)

Chap.3 : UML 10
 Contrainte sur les liens

 Au maximum un lien d'un type donné entre

deux objets donnés*
APourEpouse
Youssef : Personne APourEpouse Sondes : Personne

Chap.3 : UML 11
Contrainte sur les liens
 Au maximum un lien d'un type donné entre deux objets donnés*

APourEpouse
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 12
 Rôles

Chacun des deux objets joue un rôle diffèrent dans le lien

APourCompte
Salah : Client c1 : Compte
titulaire compte

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 13
 3 noms pour 1 concept

utilisations différentes selon le contexte

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

•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

Chap.3 : UML 14
 3.3 Associations (entre classes)
Une association décrit un ensemble de liens de même "sémantique"

APourCompte
Diagramme
Client Compte de classes
titulaire compte
(modélisation)
M1
M0
APourCompte>
Ali : Client c1 : Compte

Diagramme
APourCompte>
Salah : Client c2 : Compte d ’objets
(exemplaires)
Sana: Client c3 : Compte

Chap.3 : UML 15
 Association vs. Liens
association
classe APourCompte>

M1
Client Compte

 Un lien lie deux objets

 Une association lie deux classes M0 APourCompte>

ali : Client c1 : Compte

objets salah : Client

APourCompte>

c2 : Compte

 Un lien est une instance d’association sana : Client c3 : Compte

 Une association décrit un ensemble de liens liens

 Des liens peuvent être ajoutés ou détruits pendant l ’exécution,

(ce n ’est pas le cas des associations)

Le terme "relation" ne fait pas partie du vocabulaire UML

Chap.3 : UML 16
 Nommer les associations

Compte Banque

Compte Banque
banqueGérante
Plusieures façons de
nommer une association
Compte mais respecter la cohérence Banque
comptesGérés
entre identificateurs

Gère
Compte Banque

EstGéréPar
Compte Banque
comptesGérés banqueGérante

Chap.3 : UML 17
 Utiliser les rôles pour
«naviguer»
APourCompte
Client Compte
titulaire comptes

APourCompte>
titulaire
ali : Client c1 : Compte
comptes
ali.comptes = {c1}
salah.comptes = {c2,c3} titulaire APourCompte>
comptes
sana.comptes ={} salah : Client c2 : Compte

c1.titulaire = ali titulaire

c2.titulaire = salah sana : Client c3 : Compte

comptes
c3.titulaire = salah

Nommer en priorité les rôles

Chap.3 : UML 18
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
n..m : De n à m

 Précise combien d’objets peuvent être liés à un seul objet source

 Cardinalité minimale et cardinalité maximale ( Cmin..Cmax)

1 APourCompte 0..*
Client Compte
titulaire comptes

« Un client a 0 ou plusieurs comptes »

« Un compte a toujours 1 et 1 seul titulaire »

APourCompte>
ali : Client c1 : Compte

APourCompte>
salah : Client c2 : Compte

sana : Client c3 : Compte

Chap.3 : UML 19
Exemple de lecture d’un diagramme
Un box peut être loué par au
maximum
Un contrat un seul contrat
concerne ou peut
la location d'un
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.

Un
Unlocataire peut
contrat ne souscrire
concerne plusieurs
qu'un seul
contrat mais doit en avoir souscrit au
locataire.
moins un.

 Faites une description de ce diagramme de classe en explicitant en une

phrase chacune des multiplicités :
Box –contrat – Box ; Box – Véhicule – Box ; Contrat – Locataire – Contrat

Chap.3 : UML
Exercice de lecture d’un
diagramme de classes

Compte Banque
1..4 0..* 1..* 1..*
Client numéro numéro
titulaires solde nom
1 signataire ... 0..*
1
Consortium
CarteBleue
0..* * 1
Code
retraitMax EstAcceptéPar> 0..*
Distributeur
1..*

Chap.3 : UML 21
Exercice n°2

Description d’un système de fichiers

 Un utilisateur possède au moins un répertoire

 Un répertoire appartient à un et un seul utilisateur
 Un répertoire peut contenir d ’autres répertoires
 Un utilisateur peut accéder à au moins un répertoire
 Un répertoire peut être accédé par au moins un utilisateur
Exercice n°2 (Solution)

Contenus
<Contient
0..*
1..*
1..1 Est propriétaire de>
Contenant
Utilisateur Répertoire 0..1

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

utilisateur autorisé
Diagrammes d’objets

EstAcceptéPar>
: Distributeur
: CarteBleue
signataire

titulaires
fred : Client c4 : Compte : Banque : Consortium

: CarteBleue
signataire

ali : Client c1 : Compte : Banque

titulaires

titulaires
salah : Client c2 : Compte
: Consortium

titulaires
sana : Client c3 : Compte : Banque

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

Chap.3 : UML 24
 Diagrammes de classes vs.
d’objets
Compte
Banque
1..4 0 1 1
. . .
. . .
Client * * *
numéro
solde
... numéro
titulaires nom

 Un diagramme de classes 1 signataire

Consortium
0
.
.
*

•
CarteBleue

défini l’ensemble de tous les états possibles

0 *
.
1
.
*

Code
retraitMax

EstAcceptéPar> 0
.
.
Distributeur *

•
1
.

les contraintes doivent toujours être vérifiées

.
*

 Un diagramme d’objets s
i
g
n
a
t
a
i
ali :
Client
t
:
Carte
Bleue

c1 :
Comp
te
:

•
i a
r t n
e u q
l u
a e
i

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

t
r
i
salah e c2 :
t :
: s Com
u Cons
Client pte
l ortiu
a m
i
r
e
st
i
sana : t c3 :
:
Client u Comp
l te
B
a a
s i n
r

•
i : q
g e u
Carte
n s e
Bleue
a EstA
t ccept
a éPar

doit être conforme au modèle de classes

sophi :
i >
e: Distri
r
Client buteu
e :
EstA r
Carte
ccept
Bleue
éPar
s
>
i
g
n
a
: c1 : ali :
t
Comp Client
t a
B te
i i
a
t r
n
u e
q
u l
e a
i
t
r
i
c2 : e salah
: t
Com s :
Cons u
pte Client
ortiu l
m a
i
r
e
ts
i
c3 : t sana :
:
Comp u Client
te l
B
a a
n i s
q r i
:
u e g
Carte
e s n
Bleue
EstA a
ccept t
éPar a
: sophi
> i
Distri e:
r
buteu Client
e
r EstA

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

ccept
éPar
>


• expliquer un diagramme de classe (donner un exemple)
• valider un diagramme de classe (le "tester")

Chap.3 : UML 25
 Diagrammes de classes vs.
d’objets
Compte Banque
1..4 0..* 1..* 1..*
Client numéro
titulaires numéro
solde
nom
...
1 signataire 0..*

1
Consortium
CarteBleue
0..* * 1
Code
retraitMax EstAcceptéPar> 0..*
Distributeur
1..*

> >

: :
>

: : :

: Client : : : Consortium : Client : : : Consortium

: Client : : : Consortium

: :

...
:

: Compte : : Compte :
Banq Banq
t ue t ue
: Compte :
i i
t t Banq
t ue
u u
l l i
a a t
i i u
r r l
e e a
t
s s i
i
: Client : Compte : Client : Compte r
t
: Consortium : Consortium e
u
s
l
a : Compte
i : Consortium
r
e
s

t t t
i i i
t t t
: Client : Compte : Client : Compte
u u : : u : t
l l Banq Banq l Banq i
a a ue ue a ue t
: Client : Compte
u :
i i i
l Banq
r r r
sign a ue
e e e
s atair s s i
e : : r
e
s
:
> >

: Client : Distributeur : Distributeur : Client : Distributeur >

: Client : Distributeur
> >

>

t1 t2 t3
Chap.3 : UML 26
 Rappel

Algorithme Algorithme
Objets du du monde réel du logiciel
scénario) Objets du (scénario) Objets du
monde
logiciel langage
réel

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

Analyse Conception Code

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

Chap.3 : UML 27
 3.5 Cas particulier d’associations
Agrégation/composition

 Relation asymétrique, transitive (Relation de subordination)

 Une extrémité supporte la notion de responsabilité :
• toute opération du responsable peut se propager aux éléments
contraints

 Agrégat / agrégé : durée de vie des agrégés indépendante

de l'agrégat

 Composite / composant : durée de vie des composants

dépendante du composite / conteneur - on parle
d'embarquement

Chap.3 : UML 28
 Agrégation

Agrégation =
cas particulier d’association
+ contraintes décrivant la notion d'appartenance... ?

* Point
Figure *
x
y

Appartenance faible =
 Partage possible du composant avec d’autres Agrégat/Eléments Agrégés
 Une instance agrégée peut exister sans son agrégat et inversement

Utiliser avec précautions pendant l’analyse (ou ne pas utiliser...)

Chap.3 : UML 29
 Composition

Notion intuitive de "composants" et de "composites" ("Conteneur")

1
Pneu
4
Voiture Roue 1
Jante

composition =
cas particulier d’association
+ contraintes décrivant la notion de "composant"...

Chap.3 : UML 30
 Composition

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
Pneu
4
Voiture Roue 1
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
la même durée de vie
iii. Les composants peuvent être enlevés avant la mort du composite
Dépend de la situation modélisée !
(Ex: vente de voitures vs. casse)

Chap.3 : UML 31
 Composition

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, ses composants aussi

1..* 1..*
Chapitre Section
Document
0..*
Figure

0..1

Chap.3 : UML 32
 Composition

1 1..* 1..*
Chapitre Section
Document
0..*
Figure
M1
1..*

M0 : section
: chapitre
: section Contrainte :
: figure le graphe d'objets
: document forme un arbre
: chapitre : section (ou une forêt)
: figure
Chap.3 : UML 33
 Composition

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

M0

Chap.3 : UML 34
 Composition

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

c1 : Cercle
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 35
 3.6 Classes associatives

Pour associer des attributs et/ou des méthodes aux associations

=> classes associatives

employés sociétés
Personne 0..2 Société
*

Emploi
salaire
augmenter()

Le nom de la classe correspond au nom de l’association

(problème: il faut choisir entre forme nominale et forme verbale)

Chap.3 : UML 36
 Classes associatives
employés sociétés
Personne Société
* 0..2

Emploi
M1 salaire
augmenter()

M0 e1
salaire
salaire==1500
1500

xerox
Le salaire est une information correspondant
employé
e2 • ni à une personne,
employé
salaire = 5000
• ni à une société,
Mark ST mais à un emploi (un couple personne-société).
e3
salaire = 1000
sana employé

Chap.3 : UML 37
 Classes associatives

RAPPEL: Pour une association donnée, un couple d'objets ne peut être

connectés que par un seul lien correspondant à cette association.
(sauf si l'association est décorée par {nonunique} en UML2.0)

Emploi>
p1 Emploi> s1

Cette contrainte reste vraie dans le cas où l’association est décrite à partir
d ’une classe associative.
: Emploi
salaire = 1500

p1 s1
: Emploi
salaire = 700

Chap.3 : UML 38
 Classes associatives

employé sociétés
Personne 0..2 Société
*
Emploi e1

salaire p1 s1

Ci-dessus, une personne peut avoir deux emplois, mais pas dans la même société

e1
p1 s1
e2

employé 0..2 * société

Emploi
Personne Société
1 salaire 1
Ci-dessus, une personne peut avoir deux emplois dans la même société
Chap.3 : UML 39
 Exemple 1

Virement Virement
montant montant
Ou ?
* *
compteDébité * compteDébité 1 1 compteCrédité
{non unique}
Compte * Compte
M1 compteCrédité

M0 v1
compteDébité compteCrédité Peut-on avoir plusieurs
Situation virements entre deux
c1 c2
possible ? comptes ?
compteDébité compteCrédité
v2
Chap.3 : UML 40
 Exemple 2
Participation
nbDeButs
joueurs matchs
Joueur * Match
*

joueur * Participation * match

Joueur nbDeButs 1 Match
1 participations participations

M0 p1
joueur match Un joueur peut il avoir
Situation ali plusieurs participations à un
finale
possible ? match donné ?
joueur match
p2
Chap.3 : UML 41
 Exemple 3
CarteGrise
dateDélivrance
propriétaires voitures
Personne Voiture
* {non unique} *

propriétaire CarteGrise * voiture

*
Personne Voiture
1 carteGrises dateDélivrance carteGrises 1

M0 cg1
propriétaires voitures
Situation ali la106
possible ?
propriétaires voitures
cg2
Chap.3 : UML 42
 Exemple 4
Veuvage Veuvage
date date
montantAssurance Ou ? montantAssurance
conjointLaisséVeuf
* 0..1
0..1
conjointLaisséVeuf 1 1 conjointDécédé

Personne *
conjointsDécédés Personne

M0 v1
conjointLaisséVeuf conjointsDécédés Peut on toucher deux
Situation ali sana fois l'assurance ?
possible ?
conjointLaisséVeuf conjointsDécédés
v2
Chap.3 : UML 43
 Classes associatives

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

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

Chap.3 : UML 44
 Associations n-aires

Généralisation des classes associatives binaires : Une association peut

relier une, deux ou plusieurs classes
Créneau
-date
-heure
-durée
durée

Salle Filière

Enseignant

Chap.3 : UML 45
3.7 Associations qualifiées

Un qualifieur est un attribut (ou un ensemble d'attributs) dont la valeur sert à

déterminer l'ensemble des instances associées à une instance via une
association.

Repertoire nom Fichier

0..1

"Pour un répertoire, à un nom donné on associe qu'un fichier

(ou 0 s'il existe aucun fichier de ce nom dans ce répertoire)."

Correspond à la notion intuitive d'index absente ci-dessous

Repertoire Fichier
*
Chap.3 : UML 46
 Exemple

* membres * <<enumeration>>
Titre
Personne Secretaire
Association1901 titre:Titre President
* 0..1 Tresorier

membres
Anis

membres
sylvia
ass1 Tresorier

President ahmed

Secretaire Taha

ass2 President

Chap.3 : UML 47
 Cardinalité des Associations Qualifiées

Cas classique: cardinalité 0..1

0..1
Banque nc Compte
0..1
Cas plus rare: cardinalité * (pas de contrainte particulière exprimée)

Banque titre Employe

* *
Cas plus rare: cardinalité 1 (généralement c'est une erreur)

nl : NumLigne
Echiquier nc : NumCol Case
1 1
0 comme cardinalité minimale, sauf si le domaine de l'attribut qualifieur est fini et
toutes les valeurs ont une image.
Chap.3 : UML 48
Attributs de l'association

Les attributs qualifieurs sont des attributs de l'association,

pas de la classe

Repertoire nom Fichier

* 0..1

nom="a" f1
r1
nom="b"

r2 nom="f" f2
r2

Exemple liens "hard" en Unix: un fichier peut correspondre à des noms

différents dans des répertoires différents
Chap.3 : UML 49
Problème classique
Souvent l'index est également un attribut de classe indexée

Solution correcte:

Repertoire nom Fichier

1 0..1
/nom
Le nom du fichier correspond au nom qu'a
le fichier dans le répertoire

2 erreurs communes:

Repertoire nom Fichier

1 1
nom
Chap.3 : UML 50
 Classes associatives : traduction

Contient
Repertoire nom Fichier
* 0..1

Transformation Les attributs du

systèmatique pour qualifieur sont des
revenir aux attributs de
concepts de base l'association
Contient
nom

Repertoire Fichier
* *
Un répertoire contient 0 ou 1
fichier pour un nom donné
Chap.3 : UML 51
 Synthèse sur les associations
sens de
lecture
Nom de rôle Nom d ’association
Cardinalités

roleA < AssociationX 0..*

ClasseA x : string ClasseB

AssociationX
Composition
attributZ Navigation
(ou agrégation )

Classe associative

Chap.3 : UML 52
3.8 Généralisation /Spécialisation

Une classe peut être la généralisation d’une ou plusieurs autres classes.

Ces classes sont alors des spécialisations de cette classe.

"Super classe"
Personne Cas général Compte

"Sous classes"
Homme Femme Compte
Cas spécifique
Epargne

Deux points de vue lié (en UML) :

• relation d'héritage
• relation de sous-typage
Chap.3 : UML 53
 Règles de généralisation (…)
 La généralisation ne porte ni nom particulier ni valeur de
multiplicité.
 La généralisation est une relation non réflexive: une classe ne peut
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.
 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
également de A.

Chap.3 : UML 54
 Relation d'héritage

Les sous-classes « héritent » des propriétés des super-classes

(attributs, méthodes, associations, contraintes)

Compte
* Banque
solde
CompteEpargne
créditer()
solde * Banque
débiter() {inv: solde > -5000}
tauxIntérêt
créditer()
débiter()
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 55
 Relation d'héritage et
redéfinitions

Compte
Une opération peut être
"redéfinie" dans les sous-classes solde
créditer()
débiter()

Permet d'associer des méthodes

CompteEpargne
spécifiques à chaque pour réaliser
une même opération
créditer()
débiter()
ajouterIntérêts ()

Chap.3 : UML 56
 Relation de sous-typage, Vision
ensembliste
Compte

Compte
M1 Epargne

M0
tout objet d’une sous-classe c3
appartient également à la c4
super-classe ce1
ce3 c4 c2
ce2
c1
Compte CompteEpargne
Chap.3 : UML 57
 Synthèse des concepts de base

 Classe  Association  Héritage

• attribut • rôle
• méthode • 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 58
 Contraintes

Les différents diagrammes d'UML expriment en fait des

contraintes :
Graphiquement
• Contraintes structurelles (un attribut dans une classe)
• Contraintes de types (sous-typage)
• Contraintes diverses (composition, cardinalité, etc.)
Via des propriétés prédéfinies
• Sur des classes
• Sur des rôles ({not unique})

C'est toutefois insuffisant => OCL

Chap.3 : UML 59
Contraintes
Contraintes