Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

Analyse et modlisation Objet avec UML

1.

DFINITION D'UML

2.

LE DIAGRAMME DE DPLOIEMENT

12

3.

LE DIAGRAMME DE CONTEXTE

13

4.

LES CAS DUTILISATION

14

5.

DIAGRAMMES DINSTANCES (OU D'OBJETS)

18

6.

DIAGRAMME DE CLASSES

19

7.

DIAGRAMMES DACTIVIT

28

8.

DIAGRAMMES D'INTERACTION, DFINITION DES OPRATIONS

32

9.

LES DIAGRAMMES TATS - TRANSITIONS

41

10.

DIAGRAMME DE PACKAGES

46

11.

Rcapitulation

47

Par quoi commencer

mme rduit l'essentiel, UML reste vaste
pour commencer votre 1re analyse, vous pouvez peut-tre vous limiter lire
le chapitre 1 Dfinition d'UML
le dbut du chapitre 4 Les cas d'utilisation, paragraphes 1 et 2
le dbut du chapitre 6 Diagramme de classes, paragraphes 1 3
le dbut du chapitre 7 Diagramme d'activits, paragraphes 1 3
le dbut du chapitre 9 Diagramme d'tats, paragraphes 1 et 2
jetez un coup d'oeil aux chapitres 2 (Diagramme de dploiement) et 5 (Les diagrammes
d'instances) qui sont trs courts
gardez le reste pour plus tard
Bibliographie pour commencer
pour de bons conseils sur la faon d'utiliser UML
UML2.0, Fowler, Campus Press
UML2 en action, Roques et Valle, Eyrolles
pour des exercices d'utilisation
UML2 par la pratique, Roques, Eyrolles
pour une prsentation plus complte des modles
Modlisation objet avec UML, Muller et Gaertner, Eyrolles

__________________________________________________________________________
Page UML 1

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________
Table dtaille

1.

DFINITION D'UML

1.1.

Qu'est-ce qu'UML

1.2.

Objectif et place d'UML dans un projet logiciel

1.3.

Approche retenue dans le prsent support

1.4.

UML en fait trop

1.5.

UML ne fait pas tout

1.6.

Rfrences, outils

1.7.

Premire dfinition des principaux modles

1.8.

L'enchanement des principaux diagrammes

11

2.

LE DIAGRAMME DE DPLOIEMENT

12

3.

LE DIAGRAMME DE CONTEXTE

13

4.

LES CAS DUTILISATION

14

5.

6.

4.1.

Concepts et construction

14

4.2.

Documentation

15

4.3.

Enrichissements possibles

16

4.4.

Rle et place des cas d'utilisation

16

4.5.

Piges et conseils

17

DIAGRAMMES DINSTANCES (OU D'OBJETS)

18

5.1.

Concepts et construction

18

5.2.

Rle et place des diagrammes d'instance

18

DIAGRAMME DE CLASSES
6.1.

Premire dfinition d'une classe

19
19

6.2.
L'bauche du diagramme de classes
6.2.1. Rgles et tapes de construction
6.2.1.1.
Premire dfinition des associations

20
20
21

6.3.

Piges et conseils

22

6.4.

L'enrichissement du diagramme de classes

23

6.5.

Le diagramme de classes finalis

23

__________________________________________________________________________
Page UML 2

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

6.5.1. Finalisation des attributs

6.5.2. Complments sur les associations
6.5.2.1.
Lagrgation
6.5.2.2.
Attributs dassociations
6.5.2.3.
Multiplicits
6.5.3. L'hritage
6.6.

7.

Plusieurs diagrammes de classe

DIAGRAMMES DACTIVIT

28

Rle et place des diagrammes dactivit

28

7.2.

Concepts de base du diagramme dactivit

28

7.3.

Diagramme d'activit pour reprsenter un algorithme

29

7.4.

Diagramme d'activits couloirs d'activits

29

7.5.

Reprsentation avec les objets utiliss

30

DIAGRAMMES D'INTERACTION, DFINITION DES OPRATIONS

8.1.

Deux formes de diagrammes dinteraction

31
31
31

32
32

8.2.
Diagrammes de squence (scnarios)
8.2.1. Premiers concepts et construction
8.2.2. Passage des messages aux oprations
8.2.2.1.
Enrichissement du diagrammes de classes
8.2.3. Naissance et disparition dun objet
8.2.4. Documentation des oprations

33
33
35
36
36
37

8.3.

38

Diagrammes de collaboration

8.4.
Piges et conseils
8.4.1. "bons" et "mauvais" scnarios
8.4.2. Comparaison de deux solutions plus globales

9.

27

7.1.

7.6.
Quelques prcisions
7.6.1. Activit ou tat?
7.6.2. Synchronisation

8.

24
24
24
25
25
27

LES DIAGRAMMES TATS - TRANSITIONS

39
39
40

41

9.1.

Premiers concepts et construction

41

9.2.

La logique et la signification du diagramme d'tats

42

9.3.
Quelques lments de modlisation complmentaires
9.3.1.
Sous-tats
9.3.2. Condition sur une transition
9.3.3. Transition sans changement d'tat

43
43
43
43

9.4.

Enrichissement du diagramme de classes

44

9.5.

Rle et place des diagrammes d'tats

44

9.6.

Piges et conseils

45

__________________________________________________________________________
Page UML 3

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

10.

DIAGRAMME DE PACKAGES

46

11.

Rcapitulation

47

__________________________________________________________________________
Page UML 4

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

1.

Dfinition d'UML

1.1.

Qu'est-ce qu'UML

UML : Unified Modeling Language

n en 1995
dfinie comme norme par lOMG (Object Management Group)
UML est une mthode de modlisation:
UML dfinit comment reprsenter visuellement un logiciel
comment dessiner un modle
et surtout quoi reprsenter sur chaque modle
UML ne dfinit pas quand ni pourquoi modliser
cela est le rle de la mthode de conduite de projet
Version courante: UML2 (adopte en 2004)
- dfinit de nouveaux modles
- apporte quelques amliorations aux modles existants
Extensions: les "profils" sont destins adapter UML un contexte spcifique
UML Real Time
UML pour les services web
1.2.

Objectif et place d'UML dans un projet logiciel

L'objectif et la place d'UML dpendent de la mthode de conduite de projet adopte

l'extrme la plus ambitieuse, UML modlise tous les dtails du futur logiciel
approche MOA (Model Driven Architecture)
approche actuellement un stade exprimental
l'extrme la plus modeste, UML (s'il est utilis) ne servira qu' clarifier quelques
points difficiles du projet
approche du RAD (Rapid Application Development) et des mthodes "agiles"
(par exemple Extreme Programming)
la modlisation, lorsqu'elle est utilise, est limite aux points qui ncessitent une
clarification
dans une approche intermdiaire, UML sert raliser le dossier d'analyse et de
conception, sans prtendre modliser tous les dtails
c'est l'approche prsente par exemple dans "UML en action", mentionn dans
la bibliographie

__________________________________________________________________________
Page UML 5

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

1.3.

_______________________________________________________

Approche retenue dans le prsent support

C'est la 3me approche qui est retenue dans le prsent support

Dans cette approche, on va voir l'utilisation d'UML
- dans l'tude de besoins
- dans l'analyse mtier
- dans la conception technique gnrale (l'architecture)
- dans la conception technique dtaille (les objets)
L'enchanement des tapes sera probablement
c o n c e p tio n g n ra le

tu d e d e s b e s o in s

c o n c e p tio n d ta ill e

a n a ly s e m t ie r

dfinition des termes

tude de besoins
dans l'approche traditionnelle, c'est ce qui aboutit au "cahier des charges"
dans les approches modernes, c'est ce qui est destin formaliser les besoins et
suivre leur prise en compte et leur volution ("requirement management")
analyse mtier (analysis en anglais)
en gnral
- part de la dfinition des besoins fonctionnels
- ignore les contraintes techniques et l'environnement d'excution
en conception objet
- se concentre sur les "objets mtier", dits aussi "objets du domain"
- ignore les objets techniques (objets applicatifs, objets d'IHM, etc.)
La conception technique
conception technique gnrale (system design en anglais)
dfinit les choix d'architecture: langage(s) utilis(s), bases de donnes, protocoles
rseau, rpartition physique du logiciel, choix d'outils d'implmentation
conception technique dtaille (object design en anglais)
dtaille l'implmentation des objets mtier
ajoute les objets techniques

__________________________________________________________________________
Page UML 6

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

1.4.

_______________________________________________________

UML en fait trop

L'objectif d'UML est d'aller jusqu' la gnration du code (MDA, vu plus haut) et de couvrir
tous les types de projets logiciels
UML propose 9 types de diagrammes
UML2 en propose 13
il y a plus de modles dans UML que ce qui est ncessaire dans la plupart des projets
l'objectif n'est pas d'utiliser tous les modles mais de choisir ceux qui sont utiles selon le type
de projet

1.5.

UML ne fait pas tout

UML concerne seulement la modlisation, on l'a dj dit; mais UML ne contient pas tous les
modles qui peuvent tre utiles
par exemple
UML ne donne aucun outil pour modliser une Interface Homme-Machine (le dessin des
pages ou des crans de l'IHM, et surtout leur enchanement la cinmatique de l'IHM)
la reprsentation d'un document XML sous forme d'un arbre d'objets UML est bien
moins lisible que sous la forme propose par Altova (XMLSpy)
la reprsentation des donnes peut tre plus lisible en modle entits-associations (le
modle conceptuel de Merise) qu'en modle relationnel
la reprsentation d'un processus est plus riche dans les modlisations spcialises
(BPMN, BPSS) qu'en UML
UML n'interdit pas d'utiliser d'autres modles en complment.
1.6.

Rfrences, outils

Si l'on veut mieux comprendre UMl, on peut en tudier les anctres :

OMT: Object Modeling Technique (Rumbaugh)
Booch
Objectory ou OOSE (Jacobson)
UML est n de la fusion de ces 3 mthodes et s'est inspire de beaucoup d'autres (Schlaer et
Mellor, Coad et Yourdon)
Quelques AGLs de conception objet

et aussi les plugins des outils de dveloppement

(en particulier Eclipse)
1.7.

Premire dfinition des principaux

Rational Rose
Poseidon
Power designer et AMC designer
Mega
Together
Argo UML

modles
__________________________________________________________________________
Page UML 7

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

Sur les 13 types de diagrammes, 8 ou 9 au maximum sont importants dans l'immdiat

Il y a beaucoup e choses dans la norme UML, mais, selon les pres de la mthode eux-mmes,
on peut analyser 80% des problmes avec 20% de la norme
Ce sont ces 20% qui sont dtaills ici; le reste est seulement mentionn en conclusion ( voir le
cours "UML avanc" )
Cas dutilisation
un futur
annuaire

utilisateur

administrateur

enregistrer

configurer

dcrit les interactions entre le futur systme et ses utilisateurs

Journal
AnnuairePrincipal

AnnuaireSecondaire

Classes
reprsente les types d'objets qui existeront dans le systme

Diagramme d'activits

__________________________________________________________________________
Page UML 8

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________
la n c e m e n t

s e rv e u r_ A :
S e r v e u r P r in c ip a l
[ a c tiv ]

o u v e rtu re

jo u r n a l _ A :
J o u rn a l
[ o u v e rt ]

dcrit un algorithme de traitement ou un processus

__________________________________________________________________________
Page UML 9

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

Etats-Transitions

Serveur d' annuaire

activ

dsactiv

montre les tats successfs d'un objet

Diagramme de dploiement
reprsente les machines (ou les types de machines)
sur lesquels le logiciel sera dploy

s e rv e u r

c lie n t

HTTPS

diagramme d'instances (ou d'objets)

journal_A :
Journal

annuaire_A :
AnnuairePrincipal

annuaire1 :
AnnuaireSecondaire

annuaire2 :
AnnuaireSecondaire

reprsente des instances d'objets qui existent un moment donn dans le systme
retour sur les dfinitions:
"objet"
"classe"
"instance"

Squence ( appels aussi scnarios)

montre un enchanement d'oprations entre des objets du systme
Paul:
utilisateur
administrateur

annuaire1
Annuaire

crer
__________________________________________________________________________
ajouter
Page UML 10

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

__________________________________________________________________________
Page UML 11

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

Diagramme de communication (UML2) ou de collaboration (UML1)

s e rv e u r_ A :
S e r v e u r P r in c ip a l

1 . o u v r ir

jo u r n a l _ A :
J o u rn a l

2 . a c tu a lis e r
s e rv e u r_ 1 :
S e rv e u r S e c o n d a ir e

combine la reprsentation des objets (instances), celle de leur relation, et la circulation des
appels de mthodes

Packages

package1

package2

sert simplement regrouper des classes qui

appartiennent une mme famille
.

Vocabulaire: on distingue souvent, du point de vue des types de modles

les modles dynamiques, qui reprsentent lexpression d'un comportement
diagrammes de squence, de collaboration, d'tats...
les modles statiques, qui reprsentent une structure
diagrammes de classes, de composants, de dploiement...

__________________________________________________________________________
Page UML 12

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

1.8.

_______________________________________________________

L'enchanement des principaux diagrammes

A l'intrieur d'une phase de l'analyse (et aussi de la conception technique) on retrouve toujours
le mme enchanement entre les modles
d ia g r a m m e s
de
c la s s e s
C la s s e

C la s s e

ta ts t r a n s it io n s

cas
d 'u t i l i s a t i o n
C la s s e
cas
cas

C la s s e

d ia g r a m m e s d e s q u e n c e
ta t

d ia g r a m m e s d 'a c t iv it
ta t

ta t

Les cas dutilisation reprsentent le lien avec les tapes qui ont prcd l'analyse, un point de
dpart pour l'analyse
Le diagramme de classes reprsente l'autre point de dpart, et le point d'arrive
Les diagrammes d'activits et de squence reprsentent l'implmentation des cas d'utilisation
et l'utilisation des objets.
Les diagrammes d'tats reprsentent tous les tats possibles des objets d'une classe donne.
Les mmes modles se retrouveront en conception technique, avec toutefois une importance
relative diffrente.
les objets identifis en analyse se retrouvent (avec d'autres ajouts entre temps...) dans
l'implmentation.

__________________________________________________________________________
Page UML 13

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

2.

_______________________________________________________

Le diagramme de dploiement

Il dcrit l'implantation physique du logiciel

il reprsente
les "processeurs": matriels sur lesquels sont implantes les diffrentes parties du logiciel

process: les principaux programmes excuts sur le processeur

units passives ("devices"): matriels qui n'hbergent pas le logiciel dvelopp dans le
projet (par exemple des routeurs, des multiplexeurs)

connexions: liens entre les processeurs et les devices

protocoles: les principaux protocoles utiliss sur une connexion

Un exemple de diagramme de dploiement:

<<disque>
stockage

serveur
web
servlets
pages JSP

processors et devices sont appels aussi nuds

des strotypes peuvent tre utiliss pour dfinir des types
particuliers de processeurs ou de devices

<<http>>

une configuration
bien connue

browser

java scri pt

__________________________________________________________________________
Page UML 14

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

3.

_______________________________________________________

Le diagramme de contexte

C'est une forme particulire des diagrammes de use cases ou des diagrammes de classes, qui
seront vus plus loin.
But: montrer en introduction au dossier d'analyse une vue trs globale du rle et de la place de
l'application
Contenu: on reprsente la future application comme une boite noire, et on reprsente les
principaux changes enter l'application et les utilisateurs (ou les autres applications)
Exemple
demande d'adh'sion

adhrent

cotisations reues

application
comptable

inscription
une activit

gestion des adhrents et activits

dfinition des activits

tableaux
de bord

club

__________________________________________________________________________
Page UML 15

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

4.

Les cas dutilisation

4.1.

Concepts et construction

dem ande
d 'a d h s i o n
c a rte
d 'a d h r e n t

a d h re n t
a c t i v it
s o u h a it e
a c c o rd o u
re fu s

e n r e g is t r e r u n e
a d h s io n

e n r e g is t r e r u n e
a d h s io n d e
g ro u p e

i n s c r ir e u n e
a c t iv it

a n im a t e u r d u
c lu b

p l a n if i e r u n e
a c t iv it

Notion dfinie par Jacobson

Concepts
Cas dutilisation:
un service (une fonctionnalit) attendu du systme
une fraction du comportement du systme, runie en une transaction, en rponse un
venement dclencheur venant dun acteur
Acteur:
- cest un objet extrieur au systme
- c'est une entit physique (le service Comptabilit, le chef comptable) ou un rle (le
rdacteur, le vrificateur)
Noter:
un acteur n'est pas forcment un acteur humain, mais peut tre une autre application
Message ou vnement
le message en entre dclenche un cas
le message en sortie est le rsultat du droulement du cas
Construction du diagramme
=> un cas dutilisation comporte un acteur initiateur, et ventuellement un ou n acteurs
participants
ici Adhrer est initialis par le (futur) adhrent
__________________________________________________________________________
Page UML 16

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

=> le cas dutilisation figure lensemble des interactions qui peuvent survenir entre les acteurs
et le systme, partir de lvenement dclencheur
=> le systme est vu comme une boite noire
pour chaque cas dutilisation, il y a un ensemble dvnements qui peuvent survenir
entre les acteurs participants et le systme.

__________________________________________________________________________
Page UML 17

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

4.2.

_______________________________________________________

Documentation

Le diagramme de cas d'utilisation ne suffit pas; les cas doivent imprativement tre dcrits.
UML ne dfinit pas le mode de documentation des cas d'utilisation. Si la dmarche d'analyse
attache de l'importance aux use cases, le chef de projet doit dfinir le mode de documentation
choisi:
documentation peu formelle
une description informelle peut "raconter" en quelques phrases le droulement habituel du
use case (voir l'exemple donn par Rumbaugh dans son livre sur OMT)
fiche de cas
certains proposent d'tablir une fiche de cas

Cas n xxx
Libell du cas
Catgorie les cas peuvent Par ex.: retirer de l'argent dans un distributeur automatique
tre classs par familles
Acteur principal: celui qui initie la transaction; ici le porteur de la carte bancaire
Acteurs secondaires: ceux qui participent la ralisation du cas; ici, le systme central de
gestion des cartes voles
Description du cas
dcrire sous forme textuelle le droulement du cas (de quelques lignes une page ou plus)
1. introduire la carte
2. entrer le code d'identification
3.
4.
Rgles de gestion
quelles sont les rgles qui doivent tre appliques ce cas
par ex.: limiter le montant distribu
Prconditions
dans quel tat le systme doit-il se trouver au dbut du cas?
par ex., le distributeur a termin le traitement du client prcdent ou de l'opration prcdente
Postcondition
dans quel tat le systme doit-il se trouver la fin du cas?
par ex., le distributeur est prt traiter la demande suivante du client, ou le client suivant
Exceptions
quelles sont les erreurs qui peuvent tre dclenches?
par ex.: "transaction non autorise", "rserve de billets puise", etc.
Extensions et variantes
extensions (quels sont les cas qui tendent le cas dcrit ici?); par ex. retirer de l'argent en
choisissant la devise ou les coupures
variantes; droulements (normaux) possibles autres que celui dcrit; par ex.le distributeur
peut proposer plusieurs devises diffrentes
Complments, questions en suspens
commentaires, observations, questions en attente
enregistrer une adhsion

4.3.

Enrichissements possibles

<<include>>

__________________________________________________________________________
Page UML 18
enregistrer un paiement

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

relation "utilise" ("uses" ou "includes")

ou relation "tend" ("extends")
un cas dutilisation peut inclure ( uses ) dautres cas

relation d'hritage
un cas driv hrite de la signification et du contenu ( les oprations ) de
son super-cas
planifier une activit

planifier une activit rptitive

4.4.

Rle et place des cas d'utilisation

Suivi de l'volution des besoins

dans certaines approches actuelles, on considre que les besoins ne peuvent pas tre figs
l'inventaire des cas d'utilisation sert alors tenir jour la liste des besoins pris en compte et
leur description (requirement management)
Structuration de l'analyse par les cas d'utilisation
certaines mthodes font jouer un rle d'organisation du projet aux cas d'utilisation ("use case
driven analysis")
dans cette approche
1. les cas listent les besoins analyser, implmenter et tester
2. on en tire la liste des scnarios analyser.
analyser le ou les scnario(s) correspondant au droulement normal du cas
analyser les scnarios correspondant au droulement anormal du cas
3. on s'en sert comme rfrence lors de la validation par les utilisateurs
4. on dfinit une itration en termes de use cases implments par celle-ci
5. on mesure l'avancement du projet en terme de nombre de use cases implments

__________________________________________________________________________
Page UML 19

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

4.5.

_______________________________________________________

Piges et conseils

Procder par itrations

Combien de cas d'utilisation?
ne pas tomber dans un dcoupage trop fin (dit "dcoupage fonctionnel")
Documenter
chaque cas
chaque acteur
chaque message
Les acteurs
dfinir les acteurs logiques ou les rles, plutt que les acteurs physiques
ne pas dfinir comme acteurs des objets internes au systme
le temps peut-il tre modlis en tant qu'acteur?
Ignorer les messages entre les acteurs externes
Comment choisir les cas analyser d'abord?
commencer par les cas frquents?
ou par les cas difficiles?

__________________________________________________________________________
Page UML 20

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

5.

Diagrammes dinstances (ou d'objets)

5.1.

Concepts et construction

checs :
Activit

: Activit

judo

Un objet est reprsent par un rectangle qui contient

soit le nom de la classe et celui de l'instance (spars par un double point)
soit le nom de la classe seulement

Instance
anonyme
Classe
anonyme

soit le nom de l'objet, dont la classe n'est pas encore dfinie

On peut faire figurer les

relations entre objets
toto :
Adhrent

On peut faire figurer la multiplicit ("il

y a plusieurs instances de Activit pour
une de Animateur")
et / ou les attributs significatifs

5.2.

toto :
Animateur
age : 27
diplme : ...

pratique

judo :
Activit

jjudo
udo :
Activivit
Acti

Rle et place des diagrammes d'instance

dans l'tape d'initialisation de l'analyse

- pour identifier les objets et baucher le diagramme de classes
- pour valider le diagramme de classes (attributs, multiplicits...)
__________________________________________________________________________
Page UML 21

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

- pour construire les diagrammes de squence et dinteraction

dans les tapes ultrieures
- pour montrer les interactions entre les objets
=> diagramme de collaboration, plus loin dans ce chapitre, et dans la conception technique
-

pour montrer la configuration d'un programme

en conception technique
et en rtroconception

__________________________________________________________________________
Page UML 22

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

6.

_______________________________________________________

Diagramme de classes

Le diagramme de classes est le: diagramme central de la modlisation objet; il est construit par
itrations pendant l'tape d'analyse
1. bauche du diagramme de classes
trouver les classes que l'on utilisera pour construire les diagrammes de squence
2. enrichissement partir des diagrammes de squence et des diagrammes d'tat
reporter les oprations et attributs dcouverts en construisant ces diagrammes
3. finalisation (multiplicits, hritage, etc.)
l' "bauche de diagramme de classes" est une notion de mthode dfinie par exemple dans
OMT (Rumbaugh), ou "UML en action" (Roques et Valle), mais pas dans le guide
d'utilidation d'UML
6.1.

Premire dfinition d'une classe

Chaque classe est reprsente sous la forme dun rectangle divis en 3 compartiments. Le 1er
compartiment contient le nom de la classe, le second les attributs et le 3me les oprations
Adhrent
nom
prnom
numroAdhrent
ajouterActivit()
calculerCotisation()

Une classe comporte

- un nom
- des attributs
- des comportements (les oprations)
- ventuellement des rgles ou contraintes.
habitudes d'criture:
majuscule au nom de classe
Adherent
minuscule au nom d'attribut
nom, prenom
minuscule et parenthse pour d'une opration
valider()
majuscule l'intrieur des noms composs
calculerCotisation ()
Identifiants:
- distinction entre l'identifiant fonctionnel (n de client, n de facture connus des utilisateurs)
et l'identifiant technique (adresse mmoire, OID, ignors pendant l'analyse)
- l'identifiant fonctionnel est facultatif en conception objet
- pas de formalisme pour reprsenter les identifiants.
__________________________________________________________________________
Page UML 23

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

Un attribut: une information dcrivant les objets de la classe.

unicit des noms d'attributs: l'intrieur de la classe, non entre les classes.
Une opration ou mthode implmente un comportement des objets de la classe.
Le mme nom dans diffrentes classes doit (ou devrait) dsigner la mme nature d'opration (la
mme signification pour les utilisateurs du systme).
Autre terme utiliss: proprit, terme gnrique regroupant attribut ou opration

6.2.

L'bauche du diagramme de classes

Une bauche de diagramme de classes

Animateur
nom

adherent
numero
nom

emploie
encadre
pratique

Club

possde

propose

utilise

activite
nom : String

Adresse

Salle
numero : int

6.2.1. Rgles et tapes de construction

Objets mtier et objets techniques
l'analyse doit tre faite indpendamment des futurs choix techniques
l'analyse se limite donc aux objets mtier, et ignore les objets techniques
les objets d'IHM (et les objets applicatifs en gnral) sont ignors
les objets techniques sont ignors
Dans un premier temps, on ne reprsente gnralement pas les oprations; elles vont tre
ajoutes dans la seconde phase de l'analyse, aprs avoir analys les comportements
(diagrammes d'activits, diagrammes de squence)
__________________________________________________________________________
Page UML 24

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

Les contraintes lies aux outils ne sont pas prises en compte ce stade
la localisation physique des objets est ignore
les objets sont persistants autant que ncessaire
pas de contraintes lies au langage
Rgles de simplification pour l'tape d'analyse
on fait des hypothses simplificatrices concernant la manipulation des objets
les attributs sont "publics en lecture"
il est toujours possible d'accder un objet par la valeur de ses attributs
il est toujours possible de parcourir la liste des instances d'une classe, et de choisir
dans cette liste
toutes ces simplifications seront bien sr abandonnes lors de la conception technique
et des complments seront ajouts au modle:
visibilit des proprits (priv, public, ...)
mode d'implmentation des associations (pointeurs?...)
etc.

6.2.1.1.

Premire dfinition des associations

Association:
Adhrent

mem b re

Club

un lien entre les objets de deux classes:

un adhrent est membre du club
l'animateur encadre une activit
un adhrent peut tre l'enfant d'un autre adhrent (et cela a une importance pour notre
analyse )
...
du point de vue de la signification ou du contenu ("smantique")
une assocoation est un lien durable, "structurel" entre deux objets
du point de vue technique
une association est un chemin daccs entre les instances dune classe et les instances de lautre
Nommer les associations:
ce n'est pas obligatoire si la signification est claire
plusieurs associations (entre des paires d'objets diffrents) peuvent porter le mme nom
essayer de donner un nom qui se rfre la dure, non une action
par ex. Adherent "participe " Activit, plutt que Adherent "s'inscrit " Activit

__________________________________________________________________________
Page UML 25

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

Il peut y avoir plusieurs associations diffrentes entre

deux mmes classes

Animateur

encadre

planifie

Activit

vrifier au niveau des instances qu'il s'agit bien de deux associations diffrentes

Adherent
numroAdhrent +enfant
famille

+parent

Une association peut tre rflexive

d'une instance vers une autre, dans la mme classe
Un rle dcrit la part prise par une classe dans une association

pratique

Adhrent

Animateur

Activit

Associations ternaires:
(ou n-aire): relie plus de deux classes.
toujours vrifier si l'association ne peut pas tre dcompose.
Quelques exemples de ternaires
un vhicule appartient au titulaire de la carte grise
plusieurs conducteurs habituels peuvent tre dclars pour un vhicule
un vhicule est couvert par un contrat d'assurance, qui doit couvrir tous les conducteurs
habituels
les dveloppeurs sont affects aux projets en cours
les dveloppeurs utilisent les AGLs pour raliser les projets
__________________________________________________________________________
Page UML 26

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

6.3.

_______________________________________________________

Piges et conseils

Dcouverte des objets

un objet possde des tats et des comportements
Une classe est une abstraction qui regroupe les objets semblables
tous les objets dune classe partagent le mme comportement et les mmes attributs
Par rapport aux entits, pour les "merisiens",
- une entit peut se dcomposer en plusieurs classes (classe Adhrent et classe Adresse)
- une classe peut regrouper plusieurs entits (relation maitre-dtail par exemple)
- une classe peut tre cre pour structurer des comportements...
Candidats objets:
plutt trop de candidats objets, pour liminer ensuite, que pas assez pour clater ensuite un
objet en deux objets distincts
Attention aux objets cachs
Adhrent
nom

et aux associations caches

possde

Adresse

ou

Adhrent
nom
adresse

Adhrent
nom
activit pratique

Ne pas confondre l'acteur et l'objet qui le reprsente: par ex. l'acteur "utilisateur" et l'image de
l'utilisateur dans le systme.

6.4.

L'enrichissement du diagramme de classes

L'enrichissement peut se faire de 2 faons

- on gnre les squelettes de classes partir du diagramme de classes et on commence coder
plus tard, on pourra gnrer le diagramme de classes complt partir de ce qu'on aura cod
(rtro-conception)
- on continue l'analyse avec les diagrammes d'activit, d'tats, de squence
puis on enrichit les classes partir de ce qu'on a dcouvert en laborant ces diagrammes

__________________________________________________________________________
Page UML 27

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

6.5.

_______________________________________________________

Le diagramme de classes finalis

Qu'est-ce qu'un diagramme de classes "finalis"?

en fin d'analyse
les attributs d'instance sont dfinis
les oprations sont dfinies et documentes
les associations sont dfinies, avec leurs attributs ventuels et les multiplicits
hritages dfinis

Question de prsentation:
on peut faire plusieurs diagrammes pour reprsenter plusieurs points de vue sur les classes:
- arbre d'hritage des classes
- associations entre classes
- arbre d'agrgation
- liste des classes avec le dtail de leurs proprits
- etc.
en fin de conception technique
on trouvera en plus
- des attributs et mthodes statiques
- des classes abstraites, des interfaces (java), des mthodes abstrtaites pures (C++)
- des classes techniques (classes d'accs au rseau, la base de donnes)
- etc.
6.5.1. Finalisation des attributs
Les types des attributs:
un type de base (numrique, caractre...)
un type dfini pour les besoins du modle
une liste, un tableau...
etc.
Dtail d'un attribut:
- son type
- sa valeur par dfaut
par exemple:
prix: dcimal = 100
Attribut driv: attribut calculable partir des autres attributs de l'objet.

6.5.2. Complments sur les associations

6.5.2.1.

Lagrgation

PC
__________________________________________________________________________
Page UML 28
clavier

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

Relation compos-composant entre des objets

la classe d'assemblage contient les objets composs
la classe de composant contient les objets composs.
Par ex.: un vhicule, un ordinateur, etc. est compos d'lments
Parfois dsigne par "has a" (par opposition "is a" pour l'hritage).
Par rapport une association, ici
- la dure de vie des composants est souvent dpendante de celle du compos.
- les proprits des composs ont un sens pour les composants
- les oprations sur le compos affecteront souvent les composants.
Rcursivit:
Element

+compos

+composant
contient

une agrgation peut tre rcursive.

Dans ce cas, il est indispensable de donner un no de rle chaque extrmit de l'association
6.5.2.2.

Attributs dassociations
Les attributs de lien dcrivent
l'association:

date dbut

Animateur

1..*

anime

Activit

exemple: Les utilisateurs manipulent des fichiers; les droits sont dfinis pour un type
d'utilisateur et pour un type de fichier
Choix entre attributs de lien et attributs des objets lis:
Attention : selon que l'information dpend de l'un des objets (ce sera un attribut de l'objet), ou
que l'information dpend de l'association entre deux objets (ce sera un attribut de l'association)
la signification du modle est diffrente
si les droits sont un attribut du fichier
et s'ils sont un attribut de l'association fichier <-> utilisateur
6.5.2.3.

Multiplicits

__________________________________________________________________________
Page UML 29

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

Multiplicit: dfinit combien d'instances de la classe peuvent tre connectes une seule
instance de la classe associe
=> la notation est place l'oppos de celle des cardinalits dans Merise.
Symboles utiliss par la mthode unifie:

Animateur

Animateur

Animateur

Animateur

0..1

anime

0..*

anime

1..*

anime

1..3

anime

1..2

Activit

Activit

Activit

Activit

il y a 0 ou 1 animateur pour une activit

il y a 0 n animateur(s) pour une activit

il y a 1 n animateur(s) pour une activit, et une seule activit pour un animateur

il y a 1 3 animateur(s) pour une activit, et 1 2 activit(s) pour un animateur

__________________________________________________________________________
Page UML 30

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

6.5.3. L'hritage
Dfinition: dpendance entre deux classes selon laquelle une classe (la sous-classe) possde
les mmes proprits qu'une autre (la super-classe), avec des particularits modifiant ou
compltant ces proprits.
Plusieurs niveaux d'hritage sont possibles.
ne pas oublier: la relation d'hritage transmet les associations, comme les attributs et
oprations
Exemple
un adhrent possde les attributs
Personne
nom
prnom
tatCivil
majEtatCivil()

Adhrent
numroAdhrent

participe

calculerCotisation()
ajouterActivit()

Enfant
tauxRduction
calculerCotisation()

- nom, prnom, tat civil, parce qu'il hrite de Personne

- et, en propre, un numro
un adhrent possde en plus un attribut taux de rduction
la mthode calculerCotisation() figure dans Adhrent et dans Enfant
la mthode de calcul sera diffrente dans la super-classe (Adhrent) et dans la sous-classe

Rappels:
la gnralisation/spcialisation est le mcanisme de conception par lequel on rattache une
sous-classe une super-classe.
__________________________________________________________________________
Page UML 31

Activit
nom
description

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

L'hritage multiple: cas o un objet appartient plusieurs arbres d'hritage simultanment.

6.6.

Plusieurs diagrammes de classe

Rle central: le diagramme de classes centralise toutes les informations

il n'est pas question de montrer toutes les informations sur un seul diagramme
on construira des diagrammes pour montrer un aspect ou un autre des classes.
arborescence des classes (relations d'hritage) et oprations
les classes et leurs associations
l'ensemble des classes d'une catgorie
etc.

__________________________________________________________________________
Page UML 32

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

7.

Diagrammes dactivit

7.1.

Rle et place des diagrammes dactivit

Rle:
un diagramme d'activit prsente le droulement logique et chronologique d'un processus
(informatique ou non)
Utilisation:
les diagrammes d'activit peuvent tre utiliss des tapes diverses de l'analyse
- pour modliser un processus administratif
- reprsentation de l'organisation administrative actuelle ou future et de l'impact du projet
sur l'organisation du travail des utilisateurs
- BPM (business process modeling), BPR (business process reengineering)
- pour dcrire le droulement d'un use case
reprsentation des tapes d'excution du use case et des diffrents enchanements
possibles
- dans la documentation d'une classe, pour expliciter l'algorithme d'une mthode complexe
Les diagrammes d'activit peuvent prendre des formes varies
- pour reprsenter un algorithme
- pour reprsenter le rle des diffrents acteurs dans le processus (diagramme d'activits
couloirs d'activits)
- pour reprsenter l'action du processus sur les objets
- pour reprsenter les activits parallles et les synchronisations
7.2.

Concepts de base du diagramme dactivit

- lactivit
et
est un traitement
est interruptible

le dbut

et la fin

la transition
est instantane (pas de dure)
est automatique (dclenche
par la fin de l'activit)

validation

du processus

- les conditions :
(appeles aussi gardes)

enregistrement
adhsion

enregistrement
adhsion
donnes
correctes?

avec le losange
[oui ]
validation

7.3.

enregistrement
adhsion

ou sans
[OK]

[non ]

[NOK]

rejet

Diagramme

d'activit

validation

rejet

pour reprsenter un algorithme

__________________________________________________________________________
Page UML 33

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

c'est la forme la plus simple du diagramme d'activit

c'est la mme chose qu'un ordinogramme
cela permet par exemple de dessiner l'algorithme d'un use
case ou d'une opration

Important:
le diagramme d'activit est le seul modle dynamique qui
permette facilement de zoomer
il permet de donner une vue d'ensemble d'un processus (avec
des macro-activits) puis de dtailler chaque macro-activit
dans un sous-diagramme
Il est beaucoup plus difficile de donner une vue d'ensemble
dans les diagrammes d'tats ou de squences

7.4.

Diagramme d'activits couloirs d'activits

le candidat : adhrent

dans la modlisation d'un

processus , un couloir
d'activit (swimlane) est
souvent utilis pour
reprsenter un acteur
responsable d'une activit

: accueil club

: compta club

tablir chque

vrifier

on peut utiliser un couloir

mettre
l'encaissement
pour reprsenter le logiciel,
et les autres couloirs pour
reprsenter les acteurs (utilisateurs, dpartements de l'entreprise) qui interagissent avec le
logiciel
2 couloirs peuvent reprsenter 2 parties de l'application qui dialoguent (le client et le serveur
par exemple)
chaque couloir peut aussi reprsenter un objet
c'est une forme adapt la reprsentation de l'organisation administrative et de l'impact du
projet sur cette organisation
__________________________________________________________________________
Page UML 34

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

7.5.

_______________________________________________________

Reprsentation avec les objets utiliss

comme dans le diagramme d'objets, les rectangles reprsentent des objets ou instances (pas des
classes)
les objets peuvent tre des instances
des "candidats objets" dfinis dans
dbut de l'enregistrement
l'bauche du diagramme de classes
les flches continues reprsentent le
"flot de contrle" (la logique
d'enchanement des oprations)
les flches pointilles reprsentent
les "flots de donnes" (cration,
modification, lecture du contenu des
objets)

enregistrer les infos

sur l'adhrent

: Adhesion
[incomplte]

: Adhesion
[complte]

[ donnes
incompltes ]

: Tarif
complter

il n'est pas ncessaire de faire figurer

tous les objets
l'tat des objets peut tre prcis

[ ok ]
montant selon catg

calculer la
cotisation

ce peut tre une prparation aux

diagrammes de squence
et aussi une faon de commencer analyser les tats (que l'on va voir l'tape suivante avec
les diagrammes d'tat-transition.

__________________________________________________________________________
Page UML 35

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

7.6.

_______________________________________________________

Quelques prcisions

7.6.1. Activit ou tat?

une
activit

une activit est instantane (pas de

dure, l'chelle de temps du logiciel
modlis)

enregistrer les infos

sur l'adhrent

[ donnes
incompltes ]

un
tat

par opposition une activit, un tat a

une dure
[ ok ]

attente infos
complmentaires
do/ relancer

expiration dlai

rception infos
manquantes

abandon

calculer la
cotisation

un tat peut tre actif:

- l'objet qui est dans cet tat peut faire un traitement pendant le temps o il est dans l'tat
reprsent (par exemple envoyer des messages priodiques pour savoir si une liaison n'est pas
tombe)
- ou bien il peut tre l'coute et ragir lorsqu'un vnement se produit (par exemple un socket
serveur, en attente de demande de connexion par les clients)
la raction l'vnement peut tre la sortie de l'tat, ou simplement la production d'un message
ou vnement en rponse.
7.6.2. Synchronisation

enregistrement
adhsion

appeles aussi "fork et "join", ils reprsentent des

conditions "et"
Ils peuvent servir
- au niveau de l'analyse des processus, modliser des
processus administratifs qui s'excutent simultanment
- au niveau de la modlisation d'un programme,
reprsenter un programme multithread

choix mode
de paiement

calcul
cotisation

slection
activits

encaissement
cotisation

__________________________________________________________________________
Page UML 36

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

8.

Diagrammes d'interaction, dfinition des oprations

8.1.

Deux formes de diagrammes dinteraction

Objectif des diagrammes dinteraction: montrer les changes de messages ou les appels de
mthodes entre les objets

Formes:
: Adherent

activit demande :
Activite

toto : adhrent
1: demande de participation
2: place disponible?
3: oui
4: demande accepte

chronologique: diagramme de squence (ou scnario)

=> pour visualiser lenchainement des vnements partir dun vnement dclencheur
Un diagramme de
squence

1: demande de participation
:
Adherent
toto : adhrent

4: demande accepte

3: oui
activit demande
: Activite
2: place disponible?

topologique: diagramme de collaboration

=> pour montrer la place et le rle de chaque objet
Un diagramme de
collaboration

Place des diagrammes d'interaction

Les diagrammes de squence ou de communication sont plus difficiles laborer qu les
diagrammes d'activits
__________________________________________________________________________
Page UML 37

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

ils sont aussi moins intuitifs (me semble-t-il)

ils supposent que les objets aient dj t dfinis avec prcision
Pour toutes ces raisons, il est sans doute prfrable de commencer par les diagrammes
d'activits, et de rserver les diagrammes d'interaction la fin de l'analyse ou la conception
technique.

__________________________________________________________________________
Page UML 38

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

8.2.

_______________________________________________________

Diagrammes de squence (scnarios)

Le but des diagrammes de squence:

Un diagramme de squence reprsente un droulement possible d'un cas d'utilisation.
Le scnario reprsente une des squences possibles partir de l'vnement dclencheur du cas
d'utilisation, et les rponses du systme
on ne prtend pas construire une liste
exhaustive des scnarios

: Adherent
toto :

Un exemple (simplifi) :
un adhrent demande s'inscrire une activit
supplmentaire

activit

demande :
Activite

adhrent
1: demande de participation
2: place

disponible?
3: oui

4: ajouter partic ipant

5: demande

accepte

8.2.1. Premiers concepts et construction

Acteur extrieur et vnement dclencheur
un scnario est gnralement dclench par un acteur extrieur (voir les cas dutilisation);
il peut faire intervenir d'autres acteurs pendant son droulement
il peut se terminer par un envoi de rponse (ou plusieurs) aux acteurs
Instances dobjets
=> un scnario reprsente des occurences dobjets, pas des classes
=> une mme classe peut tre reprsente par plusieurs instances
Evnements (ou messages)
lacteur et les objets communiquent par une succession de messages
Opration
l'arrive d'un message vers une instance d'objet dclenche une opration
Chronologie
le diagramme de squence prsente les vnements dans leur ordre dapparition.

__________________________________________________________________________
Page UML 39

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

Structures de contrle
Les structure de contrle :
alternative: if... then... else... endif
rptititve: while... do... enddo
et toutes les structures quivalentes
Exemples de mthodes pour reprsenter des conditions ou des branchements:
(seulement si cest ncessaire la bonne comprhension du modle)
une alternative (condition)
exemple
l'adhrent veut s'inscrire une activitselon
qu'il y a de la place disponible ou non, la suite
est diffrente

: A d h e re n t

a c t iv it d e m a n d e :
A c t iv it e

to to : a d h re n t
1 : d e m a n d e d e p a r t ic ip a t io n
2 : p la c e d is p o n ib le ?

si

UML 2 propose d'utiliser des "cadres

d'interaction" pour faire ressortir ainsi les
choix (appels "alt" pour alternative) et les
boucles (loop)

5 : d e m a n d e a c c e p t e

5: dem ande

4 : a j o u t e r p a r t ic ip a n t

re je t e

une rptitive (boucle)

P ta n q u e :
A c t iv it

envoyer une convocation chaque

adhrent pqui participe lactivit

: A n im a t e u r

c o n v o c . r u n io n p t a n q u i s t e s

lo o p : p o u r c h a q u e p ta n q u is te

noter la reprsentation de plusieurs

instances dAdhrent

:A d h re n t

: A d h re n t

c o n v o c . r u n io n

c o n v o c a tio n

Valeurs retournes
on peut distinguer les questions (par ex. "demande de participation") par un trait continu
et les rponses (par ex. "demande accepte") par un trait pointill
Contraintes
Dans tous les modles, une contrainte se reprsente par un texte {entre accolades} ou [entre
crochets]

__________________________________________________________________________
Page UML 40

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

8.2.2. Passage des messages aux oprations

Dfinition des oprations
Pour exploiter les diagrammes de squence, il faut dfinir les oprations dclenches sur
chaque classe
dans le cas le plus simple, il s'agit de remplacer les messages par les oprations dclenches
par ces messages
et de distinguer les messages dclencheurs d'oprations des messages retourns en rsultat

Paramtres des oprations et valeur retourne

Les paramtres dcrivant lvnement peuvent tre
ports sur le diagramme

vnement (param1, param2...)

: rsultat

Le nom et/ou la valeur du message en retour peuvent tre ajouts lvnement envoy.
Retour sur le polymorphisme
un vnement peut comporter diffrentes sries de paramtres :
par ex. une demande dadhsion
1. avec nom, adresse
2. avec nom, adresse, date de naissance, chque joint
3. etc.

__________________________________________________________________________
Page UML 41

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

8.2.2.1.

_______________________________________________________

Enrichissement du diagrammes de classes

Une fois les oprations dfinies, l'enrichissement du diagramme de classes consiste

reporter dans chaque classe les oprations dfinies
trouver les attributs ncessaires l'excution de ces oprations
valider le rsultat, du point de vue des classes et non plus des scnarios
Notation dans le diagramme de classes
le dtail d'une opration (appel sa signature) peut comporter
- les arguments attendus et le type de la valeur retourne
par exemple
ajouter(terme1: rel, terme2: rel) : rel

- les valeurs par dfaut des arguments

par exemple
dessiner(CouleurFond: couleur = blanc, CouleurTrait: couleur = noir)
: boolen

=> permet des appels la mme mthode avec un nombre variable darguments.
Une classe avec l'affichage des
oprations et de leur signature

Adherent
numroAdhrent
calculerCotisation(dateEffet : Date) : int
ajouterActivit(nouvelleActivite : Activite) : boolean
ajouterActivit(nouvelleActivit : Activite, dateEffet : Date) : boolean

8.2.3. Naissance et disparition dun objet

le diagramme peut reprsenter la dure de vie de lobjet (du dbut dune ligne verticale sa
fin)
toto :
Adhrent

larrive du paiement de ladhrent provoque

: Appel de
cotis.

adhrent

- la cration dune instance de paiement

enregistrement paiement

- la suppression de lappel de cotisation

correspondant

:
Paiement
imputer (Paiement )
supprimer ( )

__________________________________________________________________________
Page UML 42

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

8.2.4. Documentation des oprations

Les diagrammes de squence ne donnent que le squelette dune squence doprations, il faut
documenter chaque opration.
Forme da la documentation:
-

un commentaire attach au scnario

ou un commentaire attach l'opration

dans le diagramme de classes
l'AGL peut crer la documentation du
code gnr partir de ce
commentaire

ou le pseudo-code de l'opration

ou un diagramme d'activits

toto :
Adhrent
adhrent
enregistrement paiement

:
Paiement
imputer (Paiement )

vrifier les rfrences

(n et date ) par rapport
l'appel de cotisation

__________________________________________________________________________
Page UML 43

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

8.3.

_______________________________________________________

Diagrammes de collaboration

Diagrammes de squence et diagrammes de collaboration sont quivalents:

les deux types de diagrammes reprsentent la mme information.

un
Adherent

adhrent

une
Activit

Les diagrammes de collaboration, comme les

diagrammes de squence,

dmde inscrip activit

inscription
dmde supplment cotis ation
paiement

- se basent sur la reprsentation des instances dobjets (les diagrammes dinstances)

- et reprsentent les venements ou messages entre ces objets.

dmde inscrip activ it

paiement

adhrent

un
Adherent
inscription

dmde supplment cotisation

une
Activit

un scnario peut tre facilement transform en diagramme de collaboration

un diagramme de collaboration montre le flot des messages entre les instances dobjets
plusieurs messages peuvent figurer sur un lien entre deux objets
Remarques
Reprsentation de la chronologie
ce nest en principe pas le but du diagramme de collaboration.
Cependant une notation est prvue ( consommer avec modration : on prfrera pour cela les diagrammes de
squence )
Reprsentation gnrale des contraintes
Une contrainte peut tre reprsente par un texte libre entre accolades, comme dans les autres modles
Cration et destruction dinstances dobjets:
la cration ou la destruction dune nouvelle instance dobjet est note comme une contrainte

__________________________________________________________________________
Page UML 44

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

8.4.

_______________________________________________________

Piges et conseils

Jusqu' quel niveau dtailler les scnarios?

Faire des variantes d'un scnario, ou utiliser les structures de contrle (si sinon) dans un
scnario unique?
Comment montrer l'appel d'un scnario par un autre?
8.4.1. "bons" et "mauvais" scnarios
Il y a plusieurs faons de traiter le mme cas d'utilisation
Le but: fabriquer des objets utilisables
Exemple
enregistrement d'une demande d'adhsion

: Club

: Adherent

: Adherent

: adhrent

: adhrent

ou

1: demande d'adhsion

1: crer

2: recherche prochain
numro
3: crer

2: affecter numro

3: numro attribu

4: numro attribu

placer les oprations sur les bons objets

il y a probablement des diagrammes plus justes que dautres

__________________________________________________________________________
Page UML 45

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

8.4.2. Comparaison de deux solutions plus globales

un scnario centralisateur
un Appel
de cotisat.

un
Paiement

un
Adhrent

compte
Trsorerie

adhrent
paiement cotis. annuelle
enreg. paiement

cotis. rgle
enreg. encaissement
accus de rception

un scnario dcentralisateur
un
Paiement

un
Adhrent

un Appel
de cotisat.

compte
Trsorerie

adhrent
paiement cotis. annuelle
identification Adh.

cotis. rgle
enreg. crdit
accus de rception

__________________________________________________________________________
Page UML 46

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

9.

Les diagrammes tats - transitions

9.1.

Premiers concepts et construction

Dfinition: le modle dynamique reprsente les modifications des objets dans le temps
Un diagramme appartient une classe et une seule
dfinit les tats possibles pour les instances de la classe
le diagramme peut reprsenter aussi les interactions entre les objets de classes diffrentes.
Concepts utiliss
Etat: configuration d'un objet, conditionnant le type de rponse de l'objet un certain
vnement
Un tat

exemples
- demander la fermeture d'une fentre, selon que son contenu a t
modifi ou non

actif

rsiliation

rsili

- renouveler l'adhsion d'un membre du club l'chance annuelle, selon qu'il est membre actif
ou rsili
Une transition
la matrialisation d'un tat: la valeur d'un attribut, ou d'un ensemble d'attributs, la
prsence ou le contenu d'une association
Transition: passage d'un tat un autre
Evnement: modification intervenue dans l'environnement et que l'objet doit
prendre en compte
L'vnement dclenche la transition

Un vnement

dure:
un vnement est "instantan"
un tat est durable; en fait permanent jusqu' l'arrive d'un nouvel vnement.
demande
d'adhsion

actif

Cration d'une instance

__________________________________________________________________________
Page UML 47

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

rsili

clture
exercice

Suppression d'une instance

__________________________________________________________________________
Page UML 48

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

9.2.

_______________________________________________________

La logique et la signification du diagramme d'tats

un exemple: les tats possibles d'un

adhrent

tats de
l'A dhrent

rsiliation
demande
d'adhsion

actif

rsili
radiation

complment
d'info
demande
incomplte

ractivation

en
instance

clture
exercice

demande de
suspension
suspend
u

abandon
noter:
les transitions sont orientes
(des flches, non de simples traits): ce n'est pas parce que la transition est possible dans un
sens qu'elle l'est dans l'autre

un diagramme d'tats ne dfinit pas une squence unique

il peut y avoir des boucles, plusieurs circuits, plusieurs points de cration et / ou
suppression des instances
il n'y a pas toujours des points de cration et / ou suppression des instances

un diagramme d'tats reprsente tous les tats possibles des instances de la classe
toutes les instances ne passeront pas par tous les tats

__________________________________________________________________________
Page UML 49

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

9.3.

_______________________________________________________

Quelques lments de modlisation complmentaires

9.3.1. Sous-tats
non
planifie

A l'intrieur d'un tat, l'objet peut tre dans deux ou

plusieurs sous-tats

crer

planifier

le super-tat dfinit une partie du comportement

planifie

le sous-tat prcise ce comportement

ouvrir

ouverte
ouverte

suspendre

La transition peut se faire de ou vers le super-tat, ou bien

de ou vers le sous-tat

suspendue
suspendue

supprimer

9.3.2. Condition sur une transition

Un mme vnement peut dclencher deux transitions diffrentes en fonction d'une condition
la condition est note sur la transition (transition garde)
actif

complment d'info[ dlai respect ]

en instance
complment d'info[ dlai non respect ]

9.3.3. Transition sans changement d'tat

Si cela claire l'analyse, on peut noter des transitions d'un tat vers lui-mme
faute[ moins de 3 ]

dehors la troisime faute:

surle terrain

faute[ troisime ]

sur la touche

__________________________________________________________________________
Page UML 50

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

9.4.

_______________________________________________________

Enrichissement du diagramme de classes

Consquence des tats sur la dfinition des oprations

deux tats
deux comportements
une condition dans la dfinition d'une opration
Consquence sur la dfinition des attributs
l'tat doit tre matrialis:
- plage de valeurs d'un attribut
- combinaison d'attributs
- valeur d'une association
- code tat

9.5.

Rle et place des diagrammes d'tats

Quels diagrammes d'tats faut-il faire?

- en thorie, les objets de toutes les classes possdent des tats
- en pratique seules les classes o au moins 3 tats sont identifiables mritent un diagramme
Quand faire les diagrammes d'tats?
les diagrammes d'tats ont un rle de validation:
- ils peuvent tre discuts avec les utilisateurs (pour les objets que ces derniers connaissent)
- ils servent au moins vrifier l'exhaustivit et la cohrence de l'analyse
ils peuvent avoir un rle de dcouverte et de structuration:
certains objets ont des tats connus des utilisateurs, tats qui servent mme organiser le
travail (le "workflow"); par ex. les tats successifs d'une facture, pour un processus de
facturation et d'encaissement
modliser ces tats tt dans l'analyse
le diagramme d'tats peut servir structurer le reste de l'analyse

__________________________________________________________________________
Page UML 51

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

9.6.

_______________________________________________________

Piges et conseils

Jusqu'o aller dans la modlisation des tats?

il y a beaucoup de choses qui peuvent tre reprsentes dans un diagramme d'tat
se limiter ce qui est ncessaire pour le but recherch
et ce qui est comprhensible de tous
Pas (ou pas toujours ) de "code tat" pour reprsenter les tats d'un objet
Limite entre les tats et l'hritage:
le mme objet dans deux tats, ou deux sous-classes de la mme classe?
par ex.
- bon client / client douteux : deux tats ou deux sous-classes avec des rgles de
gestion diffrentes ?
- et gros domestique / client tranger?
L'hritage du diagramme d'tats n'est pas automatique
les tats des objets de la sous-classe ne sont pas forcment ceux de la super-classe
les tats sont implments dabs les oprations,
et, dans l'implmentation, les objets de la sous-classe hritent des oprations de la
super-classe, sauf si on les surcharge
en pratique, les tats sont hrits par dfaut

__________________________________________________________________________
Page UML 52

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

10.

_______________________________________________________

Diagramme de packages

Les packages servent regrouper les lments par famille quand le projet grossit
- regrouper les cas d'utilisation
par exemple les regrouper selon l'utilisateur principal concern, ou par domaine
- regrouper les classes par problme trait
voir l'usage des packages dans le JDK de java
Exemple
lo g is t iq u e

les packages sont le plus souvent

hirarchiss:
ici
logistique
logistique.stocks

s to c k s

f o u r n is s e u r s

les packages dpendent d'autres packages (ils utilisent les lments dfinis dans d'autres
packages
ici stocks utilise fournisseurs

__________________________________________________________________________
Page UML 53

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

11.

_______________________________________________________

Rcapitulation

On essaie ici de rcapituler l'utilisation d'UML dans chaque phase du projet

Ceci est largement une question d'opinion personnelle
Ceci dpend aussi beaucoup de la nature du projet
Dans la dfinition des besoins et l'tude pralable
Dfinition des besoins
UML intervient peu ce stade
son rle se limite la plupart du temps au diagramme de cas d'utilisation
on peut aussi utiliser un outil pour rpertorier les besoins
une feuille de tableur suffira la plupart du temps pour lister les besoins, leur statut actuel, la
rfrence des documents de description
il existe aussi des outils spcialiss (par exempleRequisite Pro de Rational)

Etude pralable:
- dfinition du domaine (dfinition du primtre du projet)
- tude de faisabilit et/ou d'opportunit
on peut utiliser pour cette tape un diagramme de contexte pour dessiner le primtre du
projet
UML dans la conception technique gnrale
on prcise dans cette tape les choix techniques (langages, modes de stockage)
on dfinit l'implantation physique dans un diagramme de dploiement
on peut montrer le dcoupage en domaines par des diagrammes de packages (packages de
cas d'utilisations et/ou packages de classes)
lorsqu'on utilisera des standards (frameworks d'objets, modles de conception design
patterns-, conceptions gnriques du 2 tracks process) on pourra utiliser des diagrammes
(de classes, d'activit, de squence) pour prsenter ces standards; on rentre l dans
l'utilisation avance d'UML

__________________________________________________________________________
Page UML 54

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

UML dans l'analyse mtier

Avant d'entrer dans le dtail de la dmarche d'analyse avec UML, on va prendre une vue
gnrale
des modles utiliss pour l'analyse
des phases de l'analyse et de l'enchanement entre ces modles l'intrieur d'une phase
Les diagrammes que l'on utilisera le plus souvent seront
le diagramme de classes, imprativement, pour dfinir les classes
le diagramme de use cases et la documentation des use cases
les diagrammes d'activit et/ou les diagrammes de squence
les diagrammes d'tats
Les phases de l'analyse
L'analyse est en gnral un processus itratif; ceci est particulirement vrai en conception
objet et avec UML:
L'analyse centre sur l'laboration et l'enrichissement progressif d'un diagramme de classes,
qui synthtise l'essentiel du dossier d'analyse
Dans un cycle d'analyse simple (un petit projet) on distinguera probablement trois tapes:
initialisation
de l'analyse

diagramme de
classes

premiers
diagramme de
squence
(scnarios)

premiers
diagramme d'tats

dcouverte des
interactions

diagramme de
classes
[ avec oprations et
attributs ]

autres diagramme
de squence

autres
diagramme d'tats

finalisation
de l'analyse

cas d'utilis ation

[ premire bauche ]

diagramme de
classes
[ finalis ]

__________________________________________________________________________
Page UML 55

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

L'initialisation de l'analyse
Quand?
lorsque les objectifs sont clairs
- les besoins fonctionnels sont rpertoris
- le primtre du projet est dfini
et lorsque la phase d'tude de faisabilit / d'opportunit apparat termine:
le projet est ralisable (dans les enveloppes de temps et de budget) et rentable
Quoi?
donner une premire description des fonctionnalits prvues
et des objets qui y concourront
Comment?
en dfinissant les cas d'utilisation
ventuellement en dcrivant ces cas dans des diagrammes d'activits
en recherchant les classes mtier possibles (bauche du diagramme de classes)
Les itrations d'analyse
Quand?
lorsque la phase d'initialisation apparat termine:
- on ne dcouvre plus de nouveaux use cases
- les use cases sont compris et dcrits (textuellement, ou par des diagrammes d'activit, etc.)
Quoi?
dfinir la responsabilit et le contenu de chaque classe (oprations, attributs)
travers la ralisation de chaque use case sous la forme d'un scnario
Comment?
Dans une approche formalise (type mthode Unified Process)
- prendre un un tous les cas d'utilisation
pour chaque cas d'utilisation:
- dessiner un diagramme d'activit (si le cas est complexe, comporte des variantes, etc.)
et/ou des diagrammes de squences (un par enchanement possible)
- prendre une une toutes les classes
pour chaque classe qui semble possder plus de 2 tats:
- dfinir le diagramme d'tats
- vrifier que les oprations dfinies (probablement dans les diagrammes de squences)
implmentent bien toutes les transitions figurant sur le diagramme d'tats

__________________________________________________________________________
Page UML 56

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

Dans les approches agiles

on codera directement partir des squelettes de classes, en croisant les doigts,
ou bien
- on dfinira les responsabilits des objets
- on fera si ncessaire une maquette d'architecture
- on choisira une solution d'implmentation (si possible un design pattern prouv)
ceci sera abord dans le cours UML avanc
Dans notre approche intermdiaire
- choisir les use cases analyser en priorit
- construire les diagrammes de squence (scnarios) pour
- dcrire la ralisation de ces use cases
- enrichir le diagramme de classes partir des scnarios
La finalisation de l'analyse
Quand?
lorsque le cycle d'analyse apparat termine:
Quoi?
vrifier la cohrence de l'analyse
complter la dfinition des classes et des associations
dfinir les relations d'hritage
complter la documentation du dossier
Comment?
pas de nouveaux diagrammes
mais une rvision gnrale
Cohrence entre les diagrammes
Principe de la cohrence:
- les modles dynamiques doivent reprendre les cascades dvnements dfinies dans les
scnarios.
- la spcification des oprations doit tre cohrente avec les contraintes dcoulant du
diagramme dtats
- les tats doivent tre dcrits par les attributs des objets (ou leurs associations, ou les attributs
de leurs objets associs)
Vrifications:
- amont: o sont gnrs les vnements qui provoquent les transitions dcrites dans le modle
en cours dexamen?

__________________________________________________________________________
Page UML 57

Analyse et modlisation Objet

UML
G. Vieillechaize
uml modeles UML v6

_______________________________________________________

- aval: les vnements mis par le modle destination dautres objets sont-ils repris dans le
modle dynamique des objets concerns?
Cohrence entre diagrammes de squence et diagrammes d'tats
Reprsentent deux vues de la vie des objets
doivent s'appuyer sur la mme logique, le mme enchanement
Les vnements des diagrammes d'tats doivent se retrouver dans les diagrammes de
squences
Les conditions poses
au droulement des
oprations dans les
diagrammes d'tats
doivent se retrouver
dans la documentation
des oprations

FenetrePrincipale

:Fentre
Principale
fermer ( )

:FentreFille

Fenetre fenetreFii l le
fermer ( )

fermer ( )
FenetreFille
OK / nonOK

fermer ( ) : booleen

exemple

modifie

non modifie
sauvegarder

entrer donnes

UML dans la conception technique dtaille et la ralisation

Dans la conception technique dtaille, on tablit le diagramme de classes finalis
On peut l'tablir en ajoutant des dtails au modle d'analyse, avant de gnrer les squelettes de
classes
On peut aussi l'tablir par rtro-conception partir du code, pendant l'implmentation
Certains outils permettent de synchroniser automatiquement le code que l'on dveloppe et le
diagramme que l'on enrichit.

__________________________________________________________________________
Page UML 58