ANALYSE

ET
CONDUITE DE PROJETS

P. Bourmanne
HELMo

PLAN DU COURS

Partie I : Introduction : (#3)

Partie II : Les mthodes danalyse : (#17)

Le modle entit-association
Le modle de Bachman
Bases de donnes : gnralits
Le modle relationnel

Partie III : La modlisation objet avec UML : (#78)

Prsentation
Evaluation
Les mtiers de linformaticien dans le cadre dun dveloppement logiciel
Buts du cours

Introduction (#80)
UML : point de vue statique (diagrammes et notation) (#91)
UML : point de vue fonctionnel (diagrammes et notation) (#111)
UML : point de vue dynamique (diagrammes et notation) (#138)
Tableau rcapitulatif (#180)
Vers une mthode de dveloppement (#181)
Applications (#187)

PARTIE I
Introduction

INTRODUCTION: PRESENTATION
Cours:

1.5

1.5

1.5

1.5

1.5

1.5

1.5

Patricia Bourmanne
Laboratoires

Patricia Bourmanne
Danile Bayers

SUPPORTS ET REFERENCES

Syllabi :

Livres de rfrence :

Mthodes danalyse ; A. Clarinval; septembre 2002

Initiation aux bases de donnes ; P. Bourmanne, 2002
Concepts et mthodes de la programmation par objets; A. Clarinval;
novembre 2002

Modlisation objet avec UML , P.A. Muller, d. Eyrolles, 1997

UML et C++, guide pratique du dveloppement orient objet ; R.C.
Lee, W.M. Tepfenhart, d. Prentice Hall, 1998
Guide pratique du RUP , P. Koll, Ph. Kruchten, CampusPress, 2003
UML 2 par la pratique , P. Roques, Eyrolles, 2005
The unified modeling language, user guide , G. Booch, J. Rumbaugh,
I. Jacobson,
d. Addison-Wesley, 1999
UML 2 en concentr, manuel de rfrence , D. Pilone, d. OReilly
UML 2 et les design patterns, analyse et conception orientes objet et
dveloppement itratif ,C. Larman, d. Pearson Education

SUPPORTS ET REFERENCES (suite)

Diaporamas du cours (P. Bourmanne)

Sites :

http://www.hemes.be/saint-laurent/informatique/ressources.php
http://www.gramme.be/infopb
UML :
http://www.omg.org/technology/documents/formal/uml.htm
http://sparxsystems.com.au/uml-tutorial.html
http://sparxsystems.com.au/UML2_tutorial/UML2_Tutorial_Intro.htm

INTRODUCTION: EVALUATION

Votre participation active aux cours thoriques et

pratiques
Vos travaux lors des sances de laboratoires
Une interrogation (le lundi 24 novembre)
Un examen sur la thorie, des exercices raliser,
un projet prsenter
Modalits :
cf. http://www.gramme.be/infopb/coursSL/analyse/evaluations/Modalites_generales.pdf

INTRODUCTION : METIERS
DINFORMATICIEN
Catgories:

Dveloppement logiciel
Gestion dun parc informatique
Assistance clientle (technique et/ou logicielle)
Formation

INTRODUCTION: METIERS DU
DEVELOPPEMENT LOGICIEL

Les mtiers de linformaticien dans le cadre dun dveloppement

logiciel:
1) Le chef de projet : responsable de llaboration et de la modification du
plan de dveloppement logiciel

Rle complexe :

Comptences diffrentes pour tre capable dune ORIENTATION et

ADAPTATION dynamiques :

Les personnes
Le produit = lobjectif
Le processus = feuille de route de lquipe
Le projet grer, planifier, contrler, rectifier
Le budget

Aptitudes techniques
Talents de communication

Sera jug sur les rsultats

INTRODUCTION: METIERS
2) Lanalyste : responsable de dfinir et de communiquer aux
intervenants les fonctionnalits qui sont attendues du systme

Tches de haut niveau :

Comprendre les besoins des diffrents intervenants (utilisateurs,
investisseur, acheteur, chef de produit, )
Ngocier les exigences et faciliter lacceptation de lapplication
par le client
Documenter, hirarchiser et communiquer les exigences

Implication dans les disciplines suivantes :

Modlisation mtier/systme
Gestion et expression des exigences
Analyse (= modlisation de la description du problme)
Conception (= modlisation de la solution du problme)

10

INTRODUCTION: METIERS
Lanalyste : (suite)
Qualits

11

requises :

Habilet grer les relations entre plusieurs intervenants

Bonne comprhension du domaine du problme ou
capacit de lacqurir rapidement
Aptitude communiquer oralement de faon claire et
concise
Capacit rdiger succinctement et clairement les
exigences
Comprhension globale du cycle de vie du
dveloppement du logiciel

INTRODUCTION: METIERS
3) Larchitecte logiciel : dirige et coordonne les activits
techniques (technologies, structure et organisation du systme
logiciel) tout au long du projet; il est un centre de la communication

Rle pluridisciplinaire :

12

Exprience des problmes (comprhension approfondie des exigences) et

de lingnierie logicielle (vision globale du projet, comprhension des
technologies, )
Leadership technique ( chef de projet : leadership pour les aspects
mtier et administratif)
Sens de la communication
Concentration sur les objectifs et la proactivit: pour axer le projet sur les
rsultats

Source de travail : principalement exigences tablies par les analystes

Doit tre capable de cerner rapidement les situations et les problmes,
dmettre des jugements aviss et critiques en labsence
dinformations compltes
Collaboration troite avec le chef de projet (architecte + chef de projet
= gestionnaires)

INTRODUCTION: METIERS
Larchitecte logiciel : (suite)
Architecture logicielle =
structure du systme logiciel
+ aspects suivants:

13

Usage
Fonctionnalit
Performance
Robustesse
Rutilisation
Comprhensibilit
Contraintes et compromis conomiques et technologiques
Aspects esthtiques

en se concentrant uniquement sur les dcisions de conception

importantes (effets long terme sur les performances, la qualit,
lvolutivit du systme)

INTRODUCTION: METIERS
4) Le dveloppeur : charg de traduire les exigences en code excutable
dune qualit suffisante

Tches de haut niveau :

Collaboration troite :

14

Comprendre les exigences (notamment par les cas dutilisation) et les

contraintes de conception
Matriser la technologie dimplmentation et des outils utiliser
Concevoir, implmenter et tester les logiciels et les bases de donnes
Intgrer ses travaux de dveloppement ceux des autres dveloppeurs
tre cratif en restant rationnel
Veiller la qualit
avec larchitecte pour garantir que la conception respecte larchitecture globale
avec lanalyste pour lui faire part dincohrences ou de lacunes au niveau des
exigences ; lanalyste pourra alors procder aux corrections ncessaires

INTRODUCTION: METIERS
5) Le testeur : charg de lvaluation de la qualit du
logiciel et du respect des objectifs

Mission :
valuer le produit logiciel en fonction de critres appropris
(qualit perue, conformit aux normes, dcouverte de dfauts,
)
Communiquer ses valuations aux dveloppeurs, aux
managers, ventuellement aux clients
rsoudre les conflits entre les diffrentes visions dune bonne
qualit (rle ingrat : cot de la qualit)
Amener ventuellement lquipe se rendre compte que les
spcifications ntaient pas compltes
Dtecter les conditions exceptionnelles qui pourraient rendre le
logiciel inutilisable

15

INTRODUCTION: METIERS
Un

rle peut tre tenu par une ou plusieurs

personnes
Une personne peut endosser plusieurs rles,
entirement ou partiellement
Le dveloppement logiciel est avant tout un travail dquipe(s).
Linformaticien doit tre capable :
- dautonomie
- danticipation
- de rigueur
- de communiquer (oralement et par crit)

16

Linformaticien doit pouvoir rester concentr sur ses propres activits, tout en
collaborant harmonieusement avec dautres personnes organiquement lies.

INTRODUCTION : BUTS DU COURS

Vous amener tre capable danalyser un

problme, une situation modliser
Par ce cours et vos cours de programmation:
vous amener tre capable de concevoir un
logiciel de qualit:

17

Correct : rpond aux spcifications

Robuste : rsiste aux situations difficiles
Extensible : peut tre amlior et tendu
Rutilisable : peut tre utilis par dautres logiciels

Vous amener communiquer

INTRODUCTION : BUTS DU COURS

(suite)
Vous

sensibiliser et vous former la qualit :

Confrence Espace Horizon Qualit par lASBL Entreprise &

Qualit (le 16/09/2008 3me info)
Ides principales (cf. folder fourni) :

Exigence de chaque client : La qualit pour tous et partout

Qualit = atteinte de la satisfaction des clients internes et externes
Qualit

La recherche de la qualit:

18

est un besoin universel et vital

est la rponse adapte un ensemble de besoins (qui voluent)
ne simprovise pas, se construit chaque jour
se trouve tous les niveaux de lorganisation et chacun y tient une
responsabilit
nest pas une recherche du coupable, mais la recherche du progrs
continu

Apprentissage des principes du RUP (processus de

dveloppement logiciel)

ET VOUS ?
-

19

Dans quelle catgorie mtier vous voyezvous le mieux actuellement ? Pourquoi ?

Si vous travaillez dans le dveloppement
logiciel, quel mtier vous semble le mieux
convenir votre idal ? Pourquoi ?

PARTIE II
Les mthodes danalyse
(mthodes orientes gestion de donnes )

20

CONCEPT DE DONNEE
1. Dune faon gnrale, tout ce qui est manipul
par un ordinateur est appel DONNEE.
2. Une DONNEE ELEMENTAIRE dcrit un
lment atomique du monde rel.
3. On appelle STRUCTURE DE DONNES
l'association d'un ou plusieurs noms et d'un
ensemble de donnes lmentaires
auxquelles ce ou ces noms permettent
d'accder.
21

TYPE (ABSTRAIT) DE DONNEES

Quand un informaticien dveloppe un programme, il
est normal, qu'au dpart, il ne se proccupe pas de
la reprsentation physique des donnes.
On parle alors de TYPE ABSTRAIT DE DONNES.
Celui-ci dfinit la syntaxe de la donne ou de la
structure de donnes et les oprations que l'on va
effectuer sur ce type de donnes ou de structure.

22

NOTION DENTITE
ENTIT = concept concret ou abstrait qui prsente un
intrt pour les besoins de gestion de l'entreprise.
Il est affect dun NOM et porteur de PROPRIETES
(donnes lmentaires).
INSTANCE D ENTITE = un lment particulier d'un type
d'entits, caractris par un identifiant et des valeurs des
proprits.

23

IDENTIFIANT = proprit ou ensemble de proprits qui

dfinit une et une seule instance d'un type d'entit.

NIVEAUX DABSTRACTION
3 niveaux de reprsentation :

24

LES NIVEAUX DABSTRACTION

25

Le NIVEAU EXTERNE correspond la vision particulire de chaque

utilisateur par rapport au systme d'informations de l'entreprise. Il est
vident que chacune de ces vues externes est incomplte et
partielle. Chaque utilisateur peut travailler sur des donnes
diffrentes ou sur des donnes communes d'autres utilisateurs.

Le NIVEAU CONCEPTUEL ou schma conceptuel constitue la

synthse de tous les schmas externes intgrs dans un schma
unique qui est un invariant de l'organisation, car il est indpendant
des traitements et du type d'organisation des donnes choisi. Il va
regrouper toutes les donnes lmentaires, tous les objets recenss
dans les vues externes, toutes les associations entre objets et
ventuellement toutes les rgles auxquelles doivent satisfaire toutes
les donnes.

LES NIVEAUX DABSTRACTION

26

Le NIVEAU ORGANISATIONNEL OU LOGIQUE constitue une

tape intermdiaire entre le niveau conceptuel et le niveau interne.
La description logique des donnes devra par exemple tenir compte
du type de base de donnes choisie, mais s'affranchira encore de la
reprsentation spcifique en mmoire des donnes lmentaires par
exemple.

Le NIVEAU INTERNE ou schma physique dcrit les choix

d'organisation physique des donnes (fichiers, BD, mthodes
d'accs, types d'index...).

MODELE : DEFINITIONS
Modle

27

conceptuel de donnes (MCD) :

Ensemble de rgles de structuration ou de

modlisation de l'information .
Ensemble de rgles qui permet de passer du concret
inaccessible (l'univers rel) un abstrait manipulable .
Un modle ne doit pas seulement dcrire
l'organisation des donnes, mais aussi la faon dont
on opre sur ces donnes ;
il peut tre peru comme un ensemble de structures
avec un ensemble d'oprations dfinies dessus .

METHODES DANALYSE: UTILITE

Une

mthode dfinit une dmarche

reproductible pour obtenir des rsultats
fiables
Une mthode dfinit gnralement une
reprsentation (souvent graphique) qui
permet:

28

de manipuler aisment les modles

de communiquer et dchanger linformation
entre les diffrents intervenants

METHODES DANALYSE:
LE MODELE ENTITE-ASSOCIATION
Le modle entit-association exprime la
smantique des donnes laide des
concepts:
- dentit
- dassociation entre entits
- dattribut dcrivant les entits et
associations
29

DEFINITION CONCEPTUELLE DE
DONNEES :
le modle entit-association
1. ASSOCIATION = un lien logique entre 2 entits ou plus.
Elle est souvent dfinie par un verbe ou un nom (lien
smantique) et une ou plusieurs proprits.
2. CARDINALITS d'une entit dans une association qui le
lie une autre entit = le nombre minimum et le nombre
maximum d'instances de l'association auxquelles doit
tre rattache chacune des instances de l'entit.

30

A FAIRE A DOMICILE
Lire

31

Mthodes danalyse ; A. Clarinval; septembre

2002 : chap. 3.1 : Le modle entit-association
Initiation aux bases de donnes ;
P. Bourmanne, 2002 : chap. 2 : Les donnes

DEFINITION LOGIQUE DES

DONNEES :
le diagramme de Bachman
Enregistrement logique
( = record = segment)
avec ses champs (= fields)

Lien

32

Entit
avec ses
proprits

Association

diagramme de Bachman

DIAGRAMME DE BACHMAN

Rgles de transformation dun modle entitassociation en un diagramme de Bachman :

1 entit 1 segment (propritaire ou membre)

segment propritaire

segment membre

1 association porteuse dau moins une cardinalit (0,1) ou

(1,1) 1 lien
1 association totalement porteuse de cardinalits (0,N) ou
(1,N) 1 segment membre + liens (autant de liens que dentits
associes lassociation)

33

cardinalit (0,1) ou (1,1)

A FAIRE A DOMICILE
Lire

34

Mthodes danalyse ; A. Clarinval; septembre

2002 : chap. 4 : Schma logique du stockage des
donnes
Initiation aux bases de donnes ;
P. Bourmanne, 2002 : chap. 5.3. : Types de bases
de donnes

Bases de donnes : gnralits

35

Base de donnes : dfinition

36

Ensemble structur de donnes enregistres sur

des supports accessibles par l'ordinateur,
reprsentant des informations du monde rel et
pouvant tre interrog et mis jour par une
communaut d'utilisateurs.
Fichiers informatiques regroupant un ensemble
dinformations thmatiques sous forme structure et
indexe.

Systme de gestion de base de

donnes
Logiciel

gnral qui permet l'utilisateur,

qu'il soit programmeur ou utilisateur final, de
manipuler les donnes dans des termes
abstraits, sans tenir compte de la faon dont
l'ordinateur les voit.

37

Objectifs dun S.G.B.D.

Indpendance physique des programmes aux donnes

:
indpendance entre structures de stockage et structures des donnes du monde
rel,
indpendance entre schma interne et conceptuel

Indpendance logique des programmes aux donnes :

possibilit de modifier un schma externe (vue) sans modifier le schma
conceptuel et inversment

Manipulation des donnes par des langages non

procduraux
Administration facilite des donnes (fcts pour dfinir les
donnes et changer leur dfinition)

38

Objectifs dun S.G.B.D.

Efficacit des accs aux donnes (dbit + temps de rponse)

Partage des donnes
Cohrence des donnes

contrainte dintgrit (= rgle spcifiant les valeurs permises pour

certaines donnes, ventuellement en fonction dautres donnes, et
permettant dassurer une certaine cohrence de la base de donnes) :
- unicit de cl
- contrainte rfrentielle
- contrainte de domaine

Redondance contrle des donnes

Scurit des donnes (confidentialit + cohrence si panne : une
transaction doit tre totalement excute ou pas du tout)

39

Fonctions dun S.G.B.D.

Description des donnes :

commandes pour dfinir les schmas interne, conceptuel et externe

Recherche des donnes :

commandes pour retrouver les donnes de la base rpondant un

critre plus ou moins complexe (= qualification = expression logique de
critres simples, chaque critre permettant soit de comparer un attribut
une valeur, soit de parcourir une association )

Mise jour des donnes :

commandes pour insrer des donnes dans la base, modifier des

donnes, supprimer des donnes

Fonctions qui assurent les objectifs prcits

(transformation des donnes, contrle de lintgrit des donnes,

gestion de transactions et scurit)
40

TYPES DE BD

Modle hirarchique
Modle rseau

Modle

41

relationnel

LE MODELE RELATIONNEL
Introduit

par Codd
Rsultat d'une approche formelle
mathmatique qui modlise dans une mme
thorie la notion de donnes et de
manipulations de donnes et ne fait aucune
rfrence au niveau physique
Permet de rpondre aux objectifs prcits
42

Bibliothque

43

(hypothse : 1 auteur/livre)

Titre

Date achat

Prix TVAC

Auteur

Info auteur

Germinal

10/05/90

22.5

Emile Zola

1840-1902

Le rouge et le
noir

05/08/97

25

Stendhal

1783-1842

Les mots

01/02/98

17

Jean-Paul
Sartre

1905-1980

La bte
humaine

01/06/97

30

Emile Zola

1840-1902

Titre

Date_achat

Prix TVAC

Auteur

Germinal

10/05/90

22.5

Emile Zola

Le rouge et le noir

05/08/97

25

Stendhal

Les mots

01/02/98

17

Jean-Paul Sartre

La bte humaine

01/06/97

30

Auteur

Info auteur

Emile Zola

1840-1902

Stendhal

1783-1842

Jean-Paul Sartre

1905-1980

Emile Zola

Dfinitions
ATTRIBUT

:
champ ou proprit du lot d'informations
RELATION (ou TABLE) :
liste d'attributs a1, a2, ..., an; ensemble de
lignes du tableau dfini par les attributs.
Notation : r(a1, a2, ..., an) o r est le nom de
la relation
45

Dfinitions
TUPLE

(ou LIGNE) :
ligne du tableau, instance du lot
d'informations. Une relation est donc un
ensemble de tuples et elle ne possde pas
deux tuples identiques.
COLONNE :
attribut ou ensemble des valeurs de l'attribut

46

Dfinitions
DOMAINE

:
ensemble de dfinition des valeurs des
attributs.
Soit r(a1, a2, ..., ai, ..., an) une relation, la liste des domaines: D1,
D2, ...,Di, ..., Dn dans laquelle Di est le domaine de l'attribut ai.
La relation r est un sous-ensemble du produit cartsien:
D1 x D2 x ... x Di x ... x Dn.

47

Dfinitions
ARITE

d'une relation :
nombre de ses attributs.
La relation r(a1, a2, ..., ai, ..., an) est d'arit n.
L'arit d'une relation est aussi le nombre de
colonnes de la table.

CARDINALIT

d'une relation r :
nombre de tuples (ou de lignes) de la table.

48

Dfinitions
CL

D'UNE RELATION r: ensemble

d'attributs dont les valeurs identifient un tuple
et un seul de la relation r. Une relation
possde toujours au moins une cl, c'est-dire l'ensemble de ses attributs: deux tuples
d'une relation diffrent entre eux au moins
par les valeurs d'un attribut.

49

Dfinitions

50

CL CANDIDATE :
cl d'une relation telle que tout sous-ensemble
d'attributs de cette cl n'est pas une cl. Une cl
candidate constitue donc un sous-ensemble minimal
d'attributs pouvant jouer le rle de cl.
CL PRIMAIRE :
la cl unique qui sera retenue parmi les cls
candidates. Par la suite, la cl primaire d'une relation
sera dsigne par le terme cl .

Dfinitions
CL

ETRANGERE dans une table :

cl primaire ou candidate dans une autre table

51

Dfinitions
CONTRAINTES

D'INTGRIT :
rgles smantiques auxquelles les donnes
dune base doivent obir.
Elles font partie du schma conceptuel.
But : garantir la cohrence des donnes lors
des mises jour de la base (les donnes ne
sont pas indpendantes)

52

Dfinitions

Contrainte dintgrit :

Contrainte de domaine :

exprime la smantique des donnes au moyen de proprits vrifies

par les attributs

Contrainte dintgrit dentit :

une table doit toujours avoir une cl primaire

Contrainte dintgrit rfrentielle :

toute valeur attribue une cl trangre dans une table doit exister
dans la table o cette cl se retrouve comme cl primaire ou candidate

53

Par exemple dans la relation r (employ, salaire, patron):

"un salaire est compris entre 1 000 et 2 000 "
"un employ n'a qu'un seul patron"
"un patron a au plus 15 employs"
sont des contraintes d'intgrit dfinies sur la relation r.

ALGEBRE RELATIONNELLE
Elle dfinira un cadre formel pour la
dfinition d'un langage de manipulation de
donnes dont les primitives seront les
oprations de base. Ces primitives
constitueront des oprations de haut niveau
comparables certains traitements
classiques de fichiers (tri, fusion, extraction,
dition)

54

Somme et diffrence
La

somme de deux relations r et s, note

r s est l'union ensembliste des tuples de r
et des tuples de s.
La diffrence r - s est l'ensemble des tuples
de r qui n'appartiennent pas s.

55

Produit cartsien
Soient

les relations r et s d'arits respectives

k1 et k2. Le produit cartsien r X s est la
relation d'arit k1 + k2 dont les tuples sont le
rsultat de la concatnation des tuples de r
avec ceux de s.

56

Projection
s(r) d'une relation r sur un sousensemble s de ses attributs : relation
obtenue en supprimant dans la table les
colonnes des attributs qui n'appartiennent
pas s et en ne gardant dans la nouvelle
table ainsi dfinie qu'une seule occurrence
de chaque tuple.

Projection

57

Slection

Soit :

un ensemble d'oprateurs arithmtiques et logiques: =, ,

<,>, OU, ET, NON
des oprandes: attributs et constantes
une formule F dfinie sur les attributs de r par les
oprateurs et les oprandes.

La slection dfinie par F sur r, note F (r),

est une relation, ensemble des tuples de r
qui vrifient la formule F.
58

59

Date

Vendeur

Secteur

Client

Code

Adresse

vente

1/02

JFD

17

DUPONT

C1212

LIEGE

3050

2/02

JFD

17

DURAND

C1217

BRUXELLES

4200

2/02

RF

17

DUPONT

C1212

LIEGE

1200

3/02

LM

19

MARTIN

C1420

NIVELLES

12500

3/02

RF

19

BRUYNE

C1435

NAMUR

5200

4/02

LM

17

DUPONT

C1212

LIEGE

4800

4/02

JFD

17

DAMS

C1120

VIRTON

11200

5/02

LM

17

DURAND

C1217

BRUXELLES

7500

Intersection
Intersection

de 2 tables
r1 r2 = r1 - ( r1 - r2) est dfinie comme
une table qui est constitue des tuples
communs aux relations r1 et r2

60

Jointure

Jointure de 2 relations r et s suivant la relation i j ( est

un oprateur, i et j les rangs des attributs respectivement
dans r et s) :
ensemble des tuples du produit cartsien r x s qui satisfont
la relation i j. On la note :
rs
ij

61

i et j peuvent tre remplacs par le nom des attributs

correspondants.
Cas particulier : quijointure
rs
ij

Schma relationnel

Rgles de transformation dun diagramme de Bachman

en un schma relationnel :

62

Tout segment est transpos en une relation

Une relation issue d'un segment propritaire se voit attribuer,
comme cl, l'identifiant du segment et comme proprits les
attributs du segment.
Une relation issue d'un segment membre ayant un identifiant,
se voit attribuer, comme cl, l'identifiant du segment et comme
proprits les attributs du segment ainsi que le ou les
identifiants du ou des segments propritaires.
Une relation issue d'un segment membre n'ayant pas
d'identifiant, se voit attribuer, comme cl, le ou les identifiants
du ou des segments propritaires et comme proprits les
attributs du segment membre.

Les formes normales

63

Bibliothque

64

(hypothse : 1 auteur/livre)

Titre

Date achat

Prix TVAC

Auteur

Info auteur

Germinal

10/05/90

22.5

Emile Zola

1840-1902

Le rouge et le
noir

05/08/97

25

Stendhal

1783-1842

Les mots

01/02/98

17

Jean-Paul
Sartre

1905-1980

La bte
humaine

01/06/97

30

Emile Zola

1840-1902

Titre

Date_achat

Prix TVAC

Auteur

Germinal

10/05/90

22.5

Emile Zola

Le rouge et le noir

05/08/97

25

Stendhal

Les mots

01/02/98

17

Jean-Paul Sartre

La bte humaine

01/06/97

30

Auteur

Info auteur

Emile Zola

1840-1902

Stendhal

1783-1842

Jean-Paul Sartre

1905-1980

Emile Zola

Dcomposition d'une relation

universelle
Relation universelle :
Table unique dont le schma est compos par union de tous les
attributs des tables constituant la base
Dcomposition :
Remplacement dune relation R(A1,A2, ,Am) par une collection de
relations R1, R2, , Rn obtenues par des projections de R sur des
sous-ensembles dattributs dont lunion contient tous les attributs de R
Dcomposition sans perte :
Dcomposition dune relation R en R1, R2, , Rn
telle que on ait : R = R1 R2 Rn
66

Relation Voiture

NV

67

Type

Marque Puissance Couleur

872RH75 P206A Peugeot

Bleue

975AB80 P206A Peugeot

Rouge

Dcomposition 1
NV

Type

872RH75 P206A

Bleue

975AB80 P206A

Rouge

Type

Marque Puissance

P206A Peugeot
68

Couleur

Dcomposition 2

69

NV

Type

872RH75

P206A

975AB80

P206A

Type

Puissance

Couleur

P206A

Bleue

P206A

Rouge

Type

Marque

P206A

Peugeot

Relations Vin1 et Vin2

NV

Cru

Qualit

100

Volnay

Moyen

200

Chablis

Excellent

300

Chablis

Moyen

400

Volnay

Mdiocre

500

Sancerre

Excellent

Cru

Anne

Degr

Volnay

1992

11.5

Chablis

1997

12.3

Chablis

1999

12.1

Sancerre

2002

12.0

Dpendance fonctionnelle
Dpendance fonctionnelle :
Soit une relation R(A1,A2, , An), et X et Y des sous-ensembles
de {A1,A2, , An}.
Y dpend fonctionnellement de X (XY)
si pour tout tuple t1 et t2 de R, on a :
X(t1) = X(t2) => Y(t1) = Y(t2)

71

Cl de relation :
Sous-ensemble X des attributs dune relation R(A1,A2, , An)
tel que
1.
X A1 A2 An
2.
Il nexiste pas de sous-ensemble
Y X tel que Y A1 A2 An

Dpendance fonctionnelle
Dpendance fonctionnelle lmentaire:
Dpendance fonctionnelle de la forme
X A, o A est un attribut unique
nappartenant pas X
et o il nexiste pas X X tel que
X A

72

Forme normale 1
Pre (numro national, nom, prnom,
prnom_enfants)
NN

73

Nom Prenom

Prenom_
enfants

70101210130 Dupont

Andr

Paul Anne Eric

68042110331 Durand

Ren

Jol Vincent

Forme normale 1

74

NN

Nom

Prenom

70101210130

Dupont

Andr

68042110331

Durand

Ren

NN

Prenom_enfant

70101210130

Paul

70101210130

Anne

70101210130

Eric

68042110331

Jol

68042110331

Vincent

Forme normale 2
Tarif (nom, adresse, article, prix)

75

Nom

Adresse

Article

Prix

Dupont

Angleur

Bureau

420

Dupont

Angleur

Chaise

100

Durand

Mons

Bureau

400

Durand

Mons

Chaise

110

Forme normale 2

76

Nom

Article

Prix

Dupont

Bureau

420

Dupont

Chaise

100

Durand

Bureau

400

Durand

Chaise

110

Nom

Adresse

Dupont

Angleur

Durand

Mons

Forme normale 3
Vente(date, vendeur, nom_client,
adresse_client)
Date

77

Vendeur

Nom client

Adresse client

25/02/02 11h

Dupont

Detaille

Bruxelles

25/02/02 12h

Durand

Quevy

Bruxelles

06/03/02 9h

Durand

Labro

Lige

10/03/02 10h

Dupont

Detaille

Bruxelles

Forme normale 3
Date

78

Vendeur

Nom client

25/02/02 11h

Dupont

Detaille

25/02/02 12h

Durand

Quevy

06/03/02 9h

Durand

Labro

10/03/02 10h

Dupont

Detaille

Nom client

Adresse client

Detaille

Bruxelles

Quevy

Bruxelles

Labro

Lige

Forme normale
de Boyce-Codd
Stage(personne, sport, entraneur)
Personne

Sport

Entraneur

Paul

tennis

Durand

Anne

79

escalade Van Loock

Jol

tennis

Durand

Sophie

tennis

Detaille

Paul

escalade Van Loock

Forme normale
de Boyce-Codd

80

Personne

Entraneur

Paul

Durand

Anne

Van Loock

Jol

Durand

Sophie

Detaille

Paul

Van Loock

Entraneur

Sport

Van Loock

escalade

Durand

tennis

Detaille

tennis

PARTIE III
La modlisation objet avec UML
P. Bourmanne
D. Bayers

81

PREREQUIS
Relire

le document ConceptionObjet.pdf de
P. Bourmanne (cours de POO)

82

INTRODUCTION
PLAN :
- Introduction : lapproche objet
- UML : introduction
- UML : dfinition
- UML : les trois points de vue de la modlisati
on
- UML : les diagrammes
83

Introduction : lapproche objet

La

mtaphore du Client et du Serveur :

syllabus Concepts et mthodes de la
programmation par objets dA. Clarinval
Un programme orient objets est conu et
ralis comme un rseau dobjets clients et
serveurs les uns des autres, qui schangent
des messages.

84

UML : introduction

85

UML = Unified Modeling Language

(langage unifi pour la modlisation objet)
Norme de standardisation des applications dveloppes selon le
concept de programmation objet, labore en 1994 par les Amricains
G. BOOCH et J. RUMBAUGH et le Sudois I. JACOBSON pour la
socit "Rational".
Cette norme - base sur la modlisation et la formalisation de projets
informatiques, permettant de quantifier les besoins, ressources et
relations existantes entres eux - facilite la r-utilisation des
composants programms d'une application l'autre.
Standardis par lOMG (Object Management Group) depuis 1997
La mthode UML simplifie le processus complexe de conception d'un
systme informatique en dfinissant 3 points de vue (9 diagrammes)
de modlisation .
Utilis par des centaines de projets dans le monde
Indispensable votre formation dinformaticien

UML : dfinition
UML est un langage danalyse et de conception se basant sur la cration de modles
successifs de plus en plus affins afin de mettre en place une solution au problme
tudi. Le cadre de cette modlisation est orient objet.
UML a pour objectif de se rendre indpendant de certaines parties techniques comme par
exemple le langage de programmation.
Les diffrentes phases du dveloppement avec UML peuvent tre reprsentes au
moyen dune srie de diagrammes permettant de comprendre de manire visuelle les
concepts dfinis. Tous les modles senchanent en passant de lanalyse la conception,
gagnant en complexit, saffinant au fur et mesure pour arriver llaboration finale du
modle. Les diagrammes permettent de comprendre sous diffrents angles la globalit du
cas tudi en prsentant une vue fonctionnelle, statique et dynamique de celui-ci.
Chaque diagramme exprime une partie de la structure totale, tout en tant un aspect
particulier du systme.

86

Les diagrammes sont crs par un modlisateur (analyste);

ils doivent gnralement tre valids par un expert mtier (non informaticien)

MODELE, ANALYSE ET CONCEPTION

Modle =

description abstraite dun systme ou dun processus

reprsentation simplifie qui permet de :
Comprendre
Simuler

Modlisation =

87

Description dun problme : ANALYSE

Description de la solution dun problme : CONCEPTION

UML : OBJECTIFS ET UTILISATION

Objectif : Fournir une reprsentation de concepts qui facilite et

rende efficace la communication entre les diffrents
protagonistes dun projet :

Utilisations :

88

Informaticiens
Experts mtier
Utilisateurs
Analyser et concevoir des logiciels informatiques
Communiquer sur des processus logiciels ou dentreprises
Prsenter sous forme dtaille lanalyse dun systme
(reprsentation graphique, vue dun systme)
Documenter un systme, un processus ou une organisation
existants

UML : les 3 points de vue de la

modlisation
FONCTIONNEL
diagramme de cas dutilisation

STATIQUE
diagramme de classes
diagramme de packages
diagramme dobjets
diagramme de structure composite

89

DYNAMIQUE
diagramme dtats
diagramme dactivit
diagramme de squence
diagramme de collaboration
(ou de communication)

UML : les 3 points de vue de la

modlisation (suite)

Statique:

Dynamique:

Rpertorier tous les messages que les acteurs peuvent

envoyer au systme et recevoir

Fonctionnel:

90

Identifier les concepts du mtier, les modliser en tant que

classes
Identifier les associations pertinentes entre les concepts
Rflchir aux multiplicits chaque extrmit dassociation
Ajouter des attributs aux classes

Dtailler les diffrentes faons dont les acteurs peuvent

utiliser le systme.

UML : diagrammes
Point de vue fonctionnel :
Diagramme de cas dutilisation : Premire tape dans le processus de modlisation,
un cas dutilisation dcrit textuellement une situation, une fonctionnalit, dans la
problmatique tudie. Il sagit dun scnario typique accompli par un ou plusieurs objets
modliss. Le diagramme de cas dutilisation illustre les liens entre les diffrents cas et les
intervenants dans les diffrents scnarios considrs.

Point de vue statique :

Diagramme de classes : Le diagramme de classes a pour caractristique dillustrer les
diffrents acteurs, leurs compositions et leurs associations. Une classe est la description
dun groupe dobjets possdant des proprits communes ainsi que des comportements
similaires. Lobjet est linstance dune classe particulire. Le diagramme de classes est
une reprsentation statique des diffrentes classes du modle dvelopp.

91

UML : diagrammes (suite)

Point de vue dynamique :
Diagramme dtats : Ce type de diagramme dcrit les diffrentes transitions dtats qui
soprent au cours du temps de vie dun objet. Un tat se caractrise par sa dure et sa
stabilit, il reprsente une conjonction instantane des valeurs des attributs d'un objet et
des liens avec dautres objets. Les diffrents tats de lobjet sont lis entre eux et leurs
transitions sont dclenches par certains vnements.
Diagramme dactivit : Le diagramme dactivit reprsente les activits qui ont lieu
dans le droulement dun processus. Ils reprennent des concepts des diagrammes dtats
insistant plus sur la modlisation de certaines activits avec des notions de concurrence
et de synchronisation. Les diffrentes activits reprsentent les ralisations de certaines
oprations. Le diagramme permet donc de reprsenter la succession des oprations au
cours des flux de travail (workflows).

92

UML : diagrammes (suite)

Diagrammes dinteraction : Le comportement dynamique des objets et des acteurs est

reprsent au moyen des diagrammes dinteraction :

a) Diagramme de squence : Dans ce type de diagramme, il se dgage une structure
temporelle des messages qui sont changs entre les diffrents objets impliqus dans la
ralisation dun cas dutilisation. La dimension verticale montre les enchanements
temporels des messages. Les rponses des diffrents objets aux messages reus sont
aussi clairement reprsentes et comprhensibles (dynamique de fonctionnement).
b) Diagramme de collaboration : Les diagrammes de collaboration sont une autre forme
de reprsentation du comportement dynamique des objets illustrant la ralisation dun cas
dutilisation. Cette reprsentation est quivalente, mais elle se focalise davantage sur
lorganisation des objets : ils mettent en vidence les relations entre objets par la
disposition des objets.

93

UML : POINT DE VUE STATIQUE

PLAN:
- Concepts et dfinitions de base:
-

94

Diagramme de classes
Classe et objet
Attribut et opration
Association
Agrgation et composition
Gnralisation, super-classe, sous-classe
Dpendance
Package

Exercice : diagrammes de classes

DIAGRAMME DE CLASSE
Objectif

: dcrire la structure des entits

manipules par les utilisateurs
Reprsente la structure dun code orient
objet
Reprsentation :
Classes (avec attributs et oprations), relies par:
des

associations, ou
des gnralisations
95

REPRESENTATION DUNE CLASSE

DANS UN DIAGRAMME DE CLASSE

Classe1
nomA1 : type = valeur initiale

Nom de classe
Attributs

nomA2 : type = valeur initiale

nomM1 ( nomArg1:type = valeurDefaut,

) : typeRetourn
nomM2 ( nomArg1:type = valeurDefaut,
) : typeRetourn
96

Mthodes

CLASSE ET OBJET

Classe :

abstraite dun ensemble dobjets possdant

Objet :
-

97

Reprsente la description
les mmes caractristiques
type dobjets
Exemples : classe Voiture
classe Personne

Entit aux frontires bien dfinies, possdant une identit et encapsulant un

tat et un comportement
instance (occurrence) dune classe
Exemples : ma voiture est une instance de la classe Voiture
Ch. Mathy est une instance de la classe Personne

ATTRIBUT ET OPERATION

Attribut :

Opration :

98

Reprsente un type dinformation contenu dans une

classe
Exemples :
cylindre, numro dimmatriculation de la classe Voiture
Cas particulier : attribut driv
Reprsente un lment de comportement
(service) contenu dans une classe
Exemples :
dmarrer(), avancer(), tourner() de la classe Voiture

Visibilit des attributs et des

oprations
+

public
# protected
- private
Soulign : static (variables et oprations de
classe)

99

ASSOCIATION
Association:

Reprsente une relation smantique durable

entre 2 classes
Exemple : la relation possde est une association
entre les classes Personne et Voiture : une
personne peut possder des voitures
Personne

possde
1

100

>
0 .. *

Voiture

ASSOCIATION : caractristiques

101

Lassociation est nomme (indication en italique - sur

le type de la relation).

Mme si le terme qui nomme lassociation semble

privilgier un sens, une association entre concepts est
par dfaut bidirectionnelle. Donc, implicitement,
lexemple cit inclut galement le fait quune voiture est
possde par une personne.
Par dfaut, un lien est donc navigable dans les 2 sens.
Un objet (dit objet utilisateur) peut utiliser les services
dun autre objet (dit objet utilis) selon le sens de
navigation indiqu par lassociation. Pour utiliser un
service dun objet, lobjet utilisateur envoie un message
lobjet utilis.

ASSOCIATION : caractristiques
(suite)

Indication de multiplicit aux 2 extrmits de lassociation:

intervalle dentiers >= 0 ou *
:
nombre dobjets pouvant participer la relation avec un objet de lautre
classe.
Lindication par dfaut (non note) est 1..1 que lon peut galement noter 1.
Exemple : une personne peut possder entre 0 et un nombre quelconque de
voitures; une voiture est possde par une seule personne
(= nombre quelconque)

102

Possibilit dindiquer le rle jou par chaque objet dans la relation.

Ex. entre les classes Societe et Personne :
employeur, employe
La personne voit la socit comme son employeur; la socit voit la
personne comme son employ
En gnral, les rles sont indiqus si plusieurs associations relient 2 classes.

Valeurs conventionnelles de
multiplicit

103

Un et un seul (par dfaut)

0 .. 1

Zro ou un

M .. N

De M N (entiers)

De zro plusieurs

0 .. *

De zro plusieurs

1 .. *

De un plusieurs

AGREGATION

104

Agrgation : cas particulier dassociation non

symtrique* : une classe joue un rle prdominant
par rapport lautre.
Exemple courant: agrgation exprimant une relation
de contenance.
Inutile de nommer cette association : implicitement,
elle signifie : contient, est compos de

lagrgat utilise les services du composant, pas linverse

AGREGATION FORTE: composition

Agrgation forte :
agrgation non partage :

un lment ne peut appartenir qu un seul objet, dit

agrgat composite
Donc, multiplicit du ct de lagrgat : 1

Responsabilit de lagrgat composite

concernant le cycle de vie des parties :

la destruction de lagrgat composite entrane la destruction

de tous ses lments

105

Exemples : le solde dun compte

les dents dune personne

AGREGATION FAIBLE

Agrgation faible :

106

agrgation partageable
Lexistence du composant ne dpend pas de celle du
compos un mme composant peut faire partie de
plusieurs agrgats

Exemples :
une quipe sportive est compose de personnes
une classe de 2me info est compose de personnes

GENERALISATION

107

super-classe : classe plus gnrale relie une ou

plusieurs autres classes spcialises
(sous-classes) par une relation de gnralisation
Les sous-classes hritent des proprits de leur
super-classe et peuvent comporter des proprits
spcifiques supplmentaires
Exemples : les voitures, les bateaux, les avions sont
des moyens de transport
Une classe abstraite ne sinstancie pas. Elle se
note en italique.

GENERALISATION : EXEMPLE
MoyenDeTransport
marque
modele
vitesseMax

Voiture
numeroImmatriculation
108

cylindree

Bateau
nombreVoiles

DEPENDANCE
Relation

dutilisation unidirectionnelle
Lien temporaire entre objets : association
momentane
Par exemple :
un objet A:a reoit en paramtre dun
message une rfrence sur un objet C:c
dpendance de A vers C (A utilise C)

A
109

>C

PACKAGE

Package :

Structuration dun modle en packages:

110

mcanisme de regroupement dlments (classes et

associations)
Espace de noms
Cohrence (regroupement des classes selon la smantique)
Indpendance (minimisation des relations entre classes de
packages diffrents)

Exemple : package Clientle et package Voitures

CONVENTION DE NOMMAGE

111

Nom de classe :
commence par une majuscule
Ex. : Client, Aeroport
Nom dattribut, dopration, dassociation, de rle :
commence par une minuscule, puis, ventuellement plusieurs mots
concatns commenant par une majuscule
Ex. : nom, numTel, heureDepart
Nom dassociation en italique, et souvent par forme verbale (active ou
passive) avec ventuellement un petit triangle dirig vers la classe
dsigne par la forme verbale
Ex. entre les classes Societe et Personne:
<Travaille pour, <Est employee par
Nom de rle : forme nominale, ou participe prsent/pass
Ex. entre les classes Societe et Personne :
employeur, employe
Ex. entre les classes Client et Compte :
titulaire (ou possdant), possd
Prfrable : pas daccents, de caractres spciaux

EXERCICE

Etude dun systme de rservation de vol (cf. pages 80

et suivantes de UML 2 par la pratique , P. Roques,
Eyrolles, 2005, 4me dition ou pages 66 et suivantes
dans la 2me dition:
http://www.gramme.be/infopb/coursSL\analyse\references\externes/Modelisation_statique_by_Roques.pdf )
Notions supplmentaires vues dans lexercice ( noter !) :

112

Instance persistante
Attribut driv
Classe dassociation
Contrainte sur une association({ordered})
Qualificatif

A FAIRE A DOMICILE
Lire

le chapitre 1 Objet et message du

syllabus Concepts et mthodes de la
programmation par objets dA. Clarinval
Lire le chapitre 3 Le schma conceptuel de
donnes : 3 Apports du paradigme
objet du syllabus Mthodes danalyse
dA. Clarinval

113

UML : POINT DE VUE FONCTIONNEL

PLAN :
- Concepts et dfinitions de base:
-

114

Acteur (principal/secondaire)
Cas dutilisation (CU)
Scnario

Exemples de cas dutilisation

Exemple de diagramme de cas

dutilisation
Entrer
Dbloquer les portes
Porteur de carte

Capteur
alarme
incendie
Sortir

Contrler les fraudes

Grer les cartes
Gardien

Administrateur

Systme de contrle daccs

Exemple de diagramme de cas

dutilisation

Banque centrale

Retirer de largent
Client

Consulter son
compte

Transporteur
de billets

Recharger en billets

Assurer
la maintenance

Distributeur de billets

Technicien

Diagramme de cas dutilisation

Un

diagramme de cas dutilisation :

dcrit
les

acteurs
les cas dutilisation
le systme

contient
des

117

descriptions textuelles

Le systme

Le systme est un ensemble de cas dutilisation

Le systme ne comprend pas les acteurs.
Nom du systme

Nom du
systme

118

Acteur

lment extrieur au systme qui interagit avec le systme

Rle typique jou par un humain ou un systme connexe par
rapport au systme
Ex. : un client, un guichetier, un responsable maintenance,

Une mme personne peut jouer plusieurs rles

Ex. : Maurice est directeur mais peut faire le guichetier

Plusieurs personnes peuvent jouer un mme rle

Ex. : Paul et Pierre sont deux clients

Un acteur nest pas forcment un tre humain (dispositif matriel,

)
Ex. : un distributeur de billets peut tre vu comme un acteur

119

Un acteur excute un ou plusieurs cas dutilisation

Acteur

Est reprsent par:

un petit bonhomme (stick man) avec son nom dessous ou

par un rectangle contenant le mot-cl << actor>> avec son nom dessous
ou
Par un mlange de ces 2 reprsentations

Nom
acteur

acteur humain

Nom de lacteur

acteur non humain

Pour les identifier :

120

<<actor>>
Nom de lacteur

Quelles sont les entits externes au systme qui interagissent directement

avec le systme ?

Description des acteurs

Pour chaque acteur :

choisir un identificateur reprsentatif de son rle

donner une brve description textuelle

Guichetier
121

Un guichetier est un employ de la banque.

Interface entre le systme informatique et les
clients.
Peut effectuer une srie doprations : cration dun
compte, dpt et retrait dargent, etc.

Utilit des acteurs

La dfinition dacteurs permet

didentifier les cas dutilisation

Ex. : que peut faire un guichetier ? un client ? le directeur ?

122

de voir le systme de diffrents points de vues

de dterminer des droits daccs par type dacteur
de fixer des ordres de priorit entre acteurs
...

Cas dutilisation

Un cas dutilisation (use case) dcrit:

123

Une fonctionnalit du systme vue par un acteur

(et utile ce dernier)
une suite dinteractions entre un utilisateur et le systme qui
produit un rsultat observable et intressant pour un acteur
particulier
Un comportement attendu du systme du point de vue dun ou
de plusieurs acteurs
Un service rendu par le systme

Analyse : CU dcrit CE QUE le futur systme devra faire,

sans spcifier COMMENT il le fera

Cas dutilisation

Est reprsent par un ovale. Le nom du cas est inclus dans lellipse
ou figure en-dessous
Reli par des associations participe ses acteurs
Lensemble des cas dutilisation dcrit exhaustivement les
fonctionnalits du systme (1 CU : 1 fonction mtier du systme)
Pour les identifier : par acteur, quelles sont les diffrentes manires
dutiliser le systme ?
Nom du CU

Nom CU

Nom du CU
124

Liste des proprits

(sommaire didentification)

Description des cas dutilisation

Pour chaque cas d utilisation

125

choisir un identificateur reprsentatif : commencer par un verbe

linfinitif, puis un complment du point de vue de lacteur (pas du point
de vue du systme)
raliser une description dtaille plus ou moins formelle : prciser ce
que fait le systme, ce que fait lacteur

Les cas dutilisation ne doivent pas se chevaucher

Si un cas dutilisation concerne beaucoup dacteurs, il faut
probablement le dcouper en plusieurs CU

Exemple de description dtaille

dun CU: sommaire didentification

Retirer
de largent

126

Titre : Retirer de largent

Rsum : CU qui permet un client de la banque de
retirer de largent
Acteurs : client
Prcondition :
Le distributeur contient des billets, il est en attente dune
opration, il nest ni en panne, ni en maintenance
Dbut : lorsquun client introduit sa carte bancaire dans
le distributeur.
Fin : lorsque la carte bancaire et les billets sont sortis.
Postcondition :
Le GAB contient moins de billets quau dbut du CU.
Transaction de retrait enregistre par le GAB.
Hors CU, car fonctionnalit de la banque du client :
Si de largent a pu tre retir, la somme dargent sur le compte est gale la somme dargent quil y avait avant,
moins le montant du retrait. Sinon la somme dargent sur le compte est la mme quavant.

Exemple de description dtaille

dun CU: description des scnarios
Scnario nominal = droulement normal :

Retirer
de largent

(1) le client introduit sa carte bancaire

(2) le systme lit la carte et vrifie si la carte est valide
(3) le systme demande au client de saisir son code
(4) le client saisit son code confidentiel
(5) le systme vrifie que le code correspond la carte
(6) le client choisit une opration de retrait
(7) le systme demande le montant retirer

Scnarios derreurs (se terminent brutalement) :

Carte invalide : au cours de ltape (2) si la carte est juge invalide, le

systme affiche un message derreur, rejette la carte et le cas
dutilisation se termine.
Code erron (pour la 3me fois) : au cours de ltape (5) ...

Scnarios alternatifs
127

Montant demand suprieur au solde du compte

Code erron (pour la 1re ou 2me fois)

Exemple de description dtaille

dun CU: exigences non-fonctionnelles
Exigences non-fonctionnelles :

Retirer
de largent

128

(A) Performance : le systme doit ragir dans un dlai

infrieur 4 secondes, quelle que soit laction de
lutilisateur.
(B) Rsistance aux pannes : si une coupure de courant ou
une autre dfaillance survient au cours du cas dutilisation,
la transaction sera annule, largent ne sera pas distribu.
Le systme doit pouvoir redmarrer automatiquement dans
un tat cohrent et sans intervention humaine.
(C) Rsistance la charge : le systme doit pouvoir grer
plus de 1000 retraits dargent simultanment
...

Exemple de description dtaille

dun CU: besoins IHM

Retirer
de largent

129

Besoins dIHM : dispositifs dentre-sortie la disposition

de lacteur principal:
-Lecteur de carte bancaire
-Clavier numrique
-Ecran pour laffichage des messages du GAB
-Touches autour de lcran
-Distributeur de billets
-Distributeur de tickets

Remarque : les IHM seront appliques lors de votre cours de

POO/java en 2me et de votre cours de Dveloppement Web et
applications distribues en 3me

Scnario

CU = ensemble de scnarios dutilisation dun systme relis par

un but commun du point de vue dun acteur

Le CU a un dbut et une fin identifis

Scnario = succession particulire denchanements,
sexcutant du dbut la fin du CU.
Un enchanement = unit de squence dactions
Un CU contient en gnral:
Lobjectif de

130

un scnario nominal
diffrents scnarios alternatifs
(qui se terminent de faon normale)
des scnarios derreur
(qui se terminent en chec)

lacteur
principal est
atteint

DESCRIPTION TEXTUELLE DUN CU

(en rsum)

Non normalis par UML

Exemple:
1) Identification :

Titre
Rsum
Dates de cration/modification
Version
Responsable

2) Description des scnarios (nominal, alternatifs, derreur) +

prconditions + postconditions
3) Optionnel : Exigences non-fonctionnelles (fiabilit, frquence,
confidentialit, intgrit, ) et besoins IHM

131

Acteurs principaux et secondaires

Acteur principal dun CU

Acteur secondaire dun CU

132

Celui pour qui le CU produit un rsultat observable

A gauche des CU
Rle indiqu ventuellement sur lassociation ct acteur : <<principal>>
(valeur par dfaut)
Celui pour qui le CU ne produit pas un rsultat observable par lutilisateur
Souvent sollicits pour des informations complmentaires
Peuvent uniquement consulter ou informer le systme (pas dobjectif part
entire de la part de lacteur secondaire)
A droite des CU
Rle indiqu ventuellement sur lassociation ct acteur : <<secondaire>>
Ex. : systme dauthentification appel par le distributeur de billets

Relations entre acteurs et cas

dutilisation

Guichetier

Crer Un Compte

Relation dassociation ( participe ) :

Lien entre un acteur et un cas dutilisation quil peut excuter

133

Un cas dutilisation doit tre reli au moins un

acteur

Relations entre cas dutilisation

B
Retirer de largent

134

include

A
fragment
Identifier le client

Relation dinclusion (utilisation)

Utilise pour enlever la rptition entre plusieurs cas dutilisation
Utilisation du strotype include
Un cas A (identifier le client) est inclus dans un cas B (retirer de
largent) si le comportement dcrit par le cas A est inclus dans le
comportement de B
Le CU de base B incorpore explicitement le CU A de faon
obligatoire un endroit spcifi dans ses enchanements
Le CU inclus peut porter le strotype fragment

Relations entre cas dutilisation (2)

Sur demande
du client

Relation dextension

optionnelle : le CU de base

extend

Retirer de largent
B incorpore un CU A de faon Consulter solde
optionnelle :
Ex. Le CU Consulter solde se fait uniquement
sur demande du client de la banque; il tend le CU Retirer de largent

135

Utilise lorsquun cas d'utilisation est semblable un autre, mais

ajoute de la fonctionnalit.
Utile pour reprsenter les exceptions
Utilise pour dcrire une variation du comportement normal
Souvent soumise condition exprime sous la forme dune note
Utilisation du strotype extend

Relations entre cas dutilisation (3)

Relation de gnralisation
Un cas A est une gnralisation dun cas B si B est un cas particulier
de A
A
Dposer de
largent
B

136

Dposer des
chques

Dposer du
liquide

Dposer de largent est cas dutilisation gnralis. Il devient abstrait (italique) car il
ne sinstancie pas directement, mais uniquement par le biais de lun des 2 cas
spcialiss
Distinguer 2 CU spcialiss possibilit de leur associer des acteurs secondaires

Relations entre acteurs

Uniquement

relation de
gnralisation/spcialisation
A est une gnralisation de B si tous les CU
accessibles A sont accessibles B, mais
pas linverse

137

Structuration en package
Si

les cas dutilisation sont nombreux

les regrouper par acteur
Oprations

client
Oprations administrateur
etc.

les regrouper par domaine fonctionnel

Grer

les contrats
Grer les clients
Etc.
138

Grer les
clients

ETAPES DE LA MODELISATION
FONCTIONNELLE

Identification des acteurs

Identification des CU (par acteur)
Ralisation des diagrammes de CU
Description textuelle des CU (scnarios) *
Organisation des CU (relations entre CU + packages)

PUIS description graphique * * des CU :

Modlisation dynamique:
diagramme de squence systme
diagramme dactivit

139

* Pour communiquer facilement avec les utilisateurs et sentendre sur la

terminologie mtier employe
* * Pour mieux montrer la succession des enchanements

EXEMPLES DE CAS DUTILISATION

Etude

dun guichet automatique de banque

(GAB) (cf. pages 19 et suivantes de UML 2
par la pratique , P. Roques, Eyrolles, 2005)
Etude dune caisse enregistreuse (cf. pages
52 et suivantes de UML 2 par la pratique ,
P. Roques, Eyrolles, 2005)
Notion

supplmentaire vue
( noter !) :

140

Navigabilit sur lassociation

UML : POINT DE VUE DYNAMIQUE

PLAN:
- Concepts et dfinitions de base:
-

Diagramme de squence (#140)

Diagramme de collaboration (non vu en 2me) (#147)
Diagramme dtats (#148)
-

141

Etat
Transition
Evnement
Message
Condition
Effet : action ou activit

Diagramme dactivit (#162)

Interaction Overview Diagram (non vu en 2me) (#178)

Exemples de diagrammes dynamiques UML

Rle des diagrammes dynamiques

Montrer

la succession des enchanements

Montrer la chronologie des messages
envoys et reus
Montrer quel moment un acteur est sollicit

142

DIAGRAMME DE SEQUENCE: rle

143

Visualisation des interactions entre objets selon un

point de vue temporel
Insistance sur la chronologie des envois des
messages
Mise en vidence du fonctionnement du programme
avec visualisation du temps

DIAGRAMME DE SEQUENCE:
reprsentation

Reprsentation des objets :

nomObjet : NomClasse

Axe du temps
144

rectangle avec
le nom de lobjet
soulign
ligne de vie

DIAGRAMME DE SEQUENCE :
reprsentation (suite)

Acteur principal : gauche

Objet reprsentant le systme en bote noire au
milieu
Acteurs secondaires : droite
Echange de message :
flche horizontale, de lmetteur vers le destinataire

Contrainte
temporelle

145

acteurPrincipal
{y-x < 5s } x
y

message

systeme

acteurSecondaire

Transition :
instant dmission
dun message;
peut tre nomm
(ex. : x,y)

DIAGRAMME DE SEQUENCE :
reprsentation (suite)
Flche

de retour en pointill

:PorteurCarte :GAB

:SystemeAutorisation
Demande autorisation

Autorisation (solde)

146

Bande
rectangulaire
sur ligne de
vie : Priode
dactivit =
temps
pendant lequel
un objet
effectue une
action

DIAGRAMME DE SEQUENCE :
utilisations

Documentation des CU (description de linteraction,

pas de dtail de synchronisation):

Diagramme de squence systme :

Scnario nominal

Diagramme de squence enrichi =

Diagramme de squence systme +
Principales actions internes du systme
Renvois aux scnarios alternatifs et derreur

147

Usage + informatique : messages au sens des

langages de programmation

DIAGRAMME DE SEQUENCE :
catgories de messages

Synchronisation des messages:

148

Message simple (objet client et serveur agissent dans le mme processus)

Message synchrone (metteur bloqu: attend que rcepteur ait fini de traiter le message)
Message minut (comme synchrone, sauf que lattente est limite par un timeout)
Message drobant (minut par un dlai dattente nul)
Message asynchrone (metteur non bloqu)

Message rflexif : un objet senvoie un message lui-mme

(exemple : pour indiquer des interactions internes entre composants
d un objet composite)

DIAGRAMME DE SEQUENCE :
plus loin

Prcondition et postcondition :
Prcondition

Postcondition

149

Inclusion : cadre ref pour faire rfrence un autre diagramme de

squence
lignes de vie
Rptition : cadre loop
Condition : cadre alt
ref
loop

DIAGRAMME DE COLLABORATION
Montre

les objets, les liens qui les unissent et

les messages quils schangent
Mise en vidence des relations entre objets

Rem.

150

: nappartient pas la matire de 2 me

DIAGRAMME DETATS

= statechart
= cycle de vie dune instance gnrique dune classe au fil de
ses interactions avec le monde
Utile : pour dcrire avec prcision des comportements
complexes
Seulement pour certaines classes du modle
statique :

151

Comportement ractif: si la raction un vnement dun objet

dune classe dpend de son tat tat caractrise un type de
raction
Ncessit dtats squentiels pour prciser une chronologie
dvnements

Un objet suit globalement le comportement dcrit pour sa

classe

DIAGRAMME DETATS : construction

Construction :
Description du comportement nominal dun objet :
squence dtats + transitions associes
Ajout des transitions dues aux comportements alternatifs ou
derreur
(cf. CU)
Reprsentation : graphe orient dtats et de transitions
Etat 1

Etat 2

Etat 3
152

Un objet passe
par une
succession
dtats durant
son existence

ETAT

153

Reprsente une situation durant la vie dun objet :

Condition particulire satisfaite

Activit particulire en cours

Evnement particulier en attente

Identification des tats :

Recherche intuitive base sur lexpertise mtier

Etude des attributs et des associations : valeur seuil dun attribut qui modifie la
dynamique,

Etablissement des interactions dans le comportement de chaque classe

Un tat a une dure finie, variable selon larrive dvnements
Un objet est toujours dans un tat donn pour un certain temps; il ne peut tre dans un
tat inconnu ou non dfini
Un tat est limage dune conjonction instantane des valeurs des attributs de lobjet et de
la prsence (ou absence) de liens entre lobjet et dautres objets
Etat initial : cration de linstance
Etat final : destruction de linstance (il peut exister de 0 n tats finaux)
systme qui ne sarrte pas

conditions de fin diffrentes

TRANSITION

Description de la raction dun objet suite un

vnement
Connexion unidirectionnelle reliant 2 tats (parfois non
distincts)
Etat

Etat 2

Passage dun tat lautre : instantan (car objet

toujours dans un tat connu)
Constitution :

154

Etat 1

vnement dclencheur
Condition de garde
Effet
tat cible

EVENEMENT

Occurrence dun stimulus localis dans le temps et lespace:

sert de dclencheur pour que lobjet passe dun tat un autre
(objet contrl par les vnements en provenance du systme, dun autre objet)
4 types :
Evnements externes

Signal : rception dun message (envoi asynchrone)

Call event : appel dune opration sur lobjet rcepteur
(appel synchrone)
Time event : passage du temps (after dure)
Change event : changement de la satisfaction dune condition
(when expression_boolenne)

(message au systme par

un acteur, un autre objet)

Le passage de faux vrai de lexpression

boolenne dclenche la transition

Spcification:

155

Nom de lvnement
Liste des paramtres (information circulant entre objets)
Objet expditeur
Objet destinataire
Description de la signification de lvnement

Evnements internes
(au systme)

MESSAGE
Transmission

dinformation unidirectionnelle
entre lobjet metteur et lobjet rcepteur
Communication :

La

Synchrone
(ex.: call event)
Asynchrone
(ex.: envoi dun message)

rception du message est un vnement

trait par le rcepteur

156

CONDITION (ou condition de garde)

Expression boolenne qui doit tre VRAIE lorsque

lvnement arrive pour que la transition soit dclenche
Concerne par :

Attributs de lobjet
Paramtres de lvnement dclencheur

1 vnement plusieurs transitions possibles, si

conditions de garde diffrentes
Gardes dun vnement : mutuellement exclusives
Notation : [condition]
Etat 1

157

vnement [condition]

Etat 2

EFFET

Comportement optionnel de lobjet spcifi par une transition

2 types :

Laction (ou les actions) correspond une opration dclare dans la

classe de lobjet destinataire de lvnement
A accs :

158

aux paramtres de lvnement

aux attributs de lobjet

Exemples daction :

Action (non interruptible)

Activit : squence atomique (non interruptible) dactions

MAJ dun attribut

Appel dopration
Cration/destruction dun autre objet
Envoi dun signal un autre objet

Notation : /effet

Etat 1

vnement /effet

Etat 2

EFFET (suite)

Effet dentre : entry /

Effet de sortie : exit /
Etat A
entry/A_In
exit/A_Out

Remarques :

159

Un effet dentre (de sortie) reprsente une action ou une

activit qui est excute chaque fois que lon entre (sort)
dans (de) ltat factorisation de leffet dclench par toutes
les transitions qui entrent (sortent) dans (de) ltat

une transition rflexive entrane lexcution des effets de sortie et dentre

Un vnement interne nentrane pas lexcution des effets dentre et de
sortie

Une activit interruptible sera associe un tat, non une transition; il

sagit dune activit durable (do-activity); notation : do/activit.
Cas particulier : Lorsquune activit squentielle se termine, une
transition automatique (sans vnement, avec garde ventuelle) est
dclenche

EFFET (suite)

/ opTransitionIn

Points dexcution des

oprations

Etat
entry / opEntry
do / opDo
exit / opExit

/ opTransitionOut
when(vn. interne;condition) / opChangeEventWhen
after(dure) / opTimeEventAfter
160

Modlisation dun message reu/mis

Message

reu vnement qui dclenche

une transition entre tats
Message mis action (effet) sur la
transition

161

NOTATION GENERALE DU
DIAGRAMME DETATS
Etat initial de
lobjet : cration
Etat 1
do/activit 1

Evnement(paramtres)
[condition] / effet

Etat 2
do/activit 2

Transition avec
condition et effet
Etats avec
activit
durable

162

Etat final de lobjet :

destruction

EXERCICE

Etude dun publiphone pices (cf. pages 156 et suivantes de

UML 2 par la pratique , P. Roques, Eyrolles, 2005)
Notions supplmentaires vues dans lexercice ( noter !) :

Diagramme de squence : oprateur opt

Diagramme dtats :

Etat composite ou super-tat

Transition :

163

propre (retour de lobjet au sous-tat initial)

interne (pas deffet sur ltat courant)
factorise (un super-tat permet de factoriser la transition)

Pseudo-tat history
Envoi de message un autre objet sur dclenchement dune transition :
/ send cible.message

EXERCICE
Etude

dun rveil (cf. pages 181 et suivantes

de UML 2 par la pratique , P. Roques,
Eyrolles, 2005)

164

DIAGRAMME DACTIVITE

Reprsentation de lensemble des actions ralises par le

systme, avec tous les branchements conditionnels et toutes
les boucles possibles : reprsentation de la dynamique globale
du CU
Graphe orient dactions et de transitions :

Transitions automatiques* :

tapes :

165

franchies la fin des actions

ventuellement gardes par des conditions boolennes mutuellement
exclusives
en parallle ou
en squence

* Pas de transition interne, ni de transition dclenche par un vnement

REPRESENTATION
dbut

actions
flots

Action 1

Action 2

dcision

[Not OK]
conditions
fin
166

[OK]
Action 3

EXEMPLE DE TRANSITION GARDEE

Mesurer la
temprature

[trop froid]

[trop chaud]

chauffer

REPRESENTATION 1

refroidir
Mesurer la
temprature

REPRESENTATION 2
[trop froid]
chauffer
167

[trop chaud]
refroidir

FLOTS DE CONTROLE

Les flots de contrle connectent des actions

(rectangles avec coins arrondis) pour indiquer que
laction pointe par la flche ne peut pas dmarrer
tant que laction source nest pas termine
Casser loeuf

168

Sparer le blanc du
jaune

Action source

Action pointe

FLOTS DOBJETS
Les

flots dobjets connectent des nuds

dobjets (rectangles) pour fournir des entres
(inputs) aux actions. Le nom dun tat peut
tre mis entre crochets ( [nomEtat] ).
Faire fondre le
chocolat

169

Input
pour laction
suivante

chocolat

Nud dobjet :

[fondu]

- objet soulign
- tat entre crochets

Exemple : activits dune commande

se renseigner
La responsabilit
des diffrentes
activits peut tre
rpartie sur
diffrents objets
(client, vendeur,
service
dexpdition)

commander

commande
[passe]

payer

facturer

commande
[paye]

livrer
170

tablir un
devis

bon de
livraison

BARRE DE SYNCHRONISATION
Une

171

barre de synchronisation :

reprsente une synchronisation entre flots de

contrle parallles
permet douvrir (fork = barre dembranchement)
ou de fermer (join = barre de jointure) des
branches parallles au sein dun flot dexcution
dune mthode ou dun CU

FORK
fork

: barre dembranchement
Sparer les blancs
des jaunes

Action

fork

jaunes
172

blancs

Nuds dobjets

FORK (suite)

Les transitions au
dpart dune barre de
synchronisation sont
dclenches
simultanment

Refroidir

Arrter le
chauffage

173

Arer

JOIN
join

: barre de jointure (fusion de flots)

chocolat

jaunes

[fondu]
join

Ajouter les jaunes

au chocolat fondu
174

JOIN (suite)
Arrter le
chauffage

Arer

Mesurer la
temprature

175

Une barre de
synchronisation ne
peut tre franchie que
lorsque toutes les
transitions en entre
sur la barre ont t
dclenches

ACCEPT TIME EVENT

Accept

time event
Mettre les rcipients
de mousse au frigo

Accept time
event

176

Attendre 3h

REGION DEXPANSION

Une rgion dexpansion est un nud dactivit structur qui

sexcute 1 fois pour chaque lment dans une collection
dentres. Les entres et sorties de la collection (nud
dexpansion) sont matrialiss sur la frontire de la rgion
(rectangle en pointills avec coins arrondis) par des petits
rectangles de plusieurs compartiments
Rgion
dexpansion

Mlanger les blancs la

prparation chocolat

Mlange
Verser dans un
rcipient

177

Rcipients

Mettre au
frigo

REGION INTERRUPTIBLE

Une rgion interruptible est un ensemble de nuds et darcs dactivit

au sein duquel lactivit se termine si un vnement dsign se
produit. Cet vnement dinterruption apparat comme une flche
clair

Rgion interruptible :
gestionnaire
dinterruption

Faire fondre
le chocolat

chocolat

Flot dexception
:

est brl

Recette rate

178

Nettoyer et
ranger

chocolat
[fondu]

ENVOI/RECEPTION DUN SIGNAL

Envoi dun signal

Rception dun signal

179

EXERCICE
Etude

dun guichet automatique de banque

(GAB)
(cf. pages 19 et suivantes de UML 2 par la
pratique , P. Roques, Eyrolles, 2005) :
diagramme dactivit pour le retrait dargent
page 37

180

Interaction Overview Diagram

Fusion

des diagrammes dactivit et de

squence
Actions remplaces par des interactions

Rem.

181

: nappartient pas la matire de 2 me

A FAIRE A DOMICILE

Lire

le chapitre 8 Mthodes orientes

objets du syllabus Mthodes danalyse
dA. Clarinval

182

TABLEAU RECAPITULATIF
Diagrammes de

Point de vue des cas dutilisation

cas dutilisation

Acteurs
CU
Classes
Relations

classes

183

Point de vue logique

objets

Objets
Liens

Classes
Objets
Liens

squence

Acteurs
Objets
Messages

Acteurs
Objets
Messages

collaboration

Acteurs
Objets
Liens
Messages

Acteurs
Objets
Liens
Messages

tats

Etats
Transitions

Etats
Transitions

activit

Activits
Transitions

Activits
Transitions

VERS UNE METHODE DE

DEVELOPPEMENT
Cycle

184

de vie itratif et incrmental:

Abandon de la mthode en cascade pour un

dveloppement itratif
Exemple : RUP (cf. le document : Le processus
RUP )

VERS UNE METHODE DE

DEVELOPPEMENT (suite)
Extrait de lavant-propos de :
Guide pratique du RUP , P. Koll, Ph. Kruchten, CampusPress, 2003

185

VERS UNE METHODE DE

DEVELOPPEMENT (suite)

186

VERS UNE METHODE DE

DEVELOPPEMENT (suite)

187

VERS UNE METHODE DE

DEVELOPPEMENT (suite)

188

6 ETAPES dun processus de

dveloppement (par Expert-IT SA)

Un processus dcrit:

Un processus :

utilise UML comme langage de modlisation

est un guide sur la manire dutiliser UML

6 tapes dun processus de dveloppement logiciel:

A.
B.
C.
D.
E.

189

Quoi faire
Comment le faire
Qui le fera
Quand le faire
Pourquoi le faire

F.

Besoins
Analyse des Business Process (BP)
Recueil des besoins du projet informatique
Analyse et design de lapplication
Implmentation
Logiciel fourni

6 ETAPES dun processus de

dveloppement (suite)
1)
2)

Besoins : lentreprise, dcompose en processus mtier, subit

les actions du monde extrieur
Analyse des BP :
analyse du systme dinformation humain:
a) Est alimente par :
Business Process Modeling Notation (BPMN)
Business Process Execution Language (BPEL)
Business Process Modeling Language (BPML)
Diagrammes dactivit
Diagrammes dtat diagr. de classe
Business UC
b) Produit les artefacts suivants :
BP Model
Glossaire
Model Concepts

190

6 ETAPES dun processus de

dveloppement (suite)
3)

191

Recueil des besoins du projet informatique:

a) Est aliment par :
- diagrammes CU
- diagrammes dactivit, dtat, de squence, de classes
b) Produit les artefacts suivants :
- modlisation des concepts (UML)
- catalogue des acteurs (UML)
- catalogue des CU (UML)
- catalogue des business rules (rgles communes tous
les CU)
- catalogue des besoins non fonctionnels (temps de
rponse, infrastructure Web, multilinguisme, )
- glossaire (commenc ventuellement dans lanalyse des
besoins)

Non UML:
rgles de
bonne
pratique

6 ETAPES dun processus de

dveloppement (suite)
4)

Analyse et design de lapplication :

(= comment va-t-on faire ?) :
1)
2)

5)

192

Organisation des classes du point de vue structurel et dynamique

Point de vue technique, de linfrastructure

a) Est alimente par :

- diagrammes de classe
- diagrammes dynamiques
b) Produit les artefacts suivants :
- diagrammes de classe
- modlisation dynamique
Implmentation du logiciel :
Do un feed-back sur les autres tapes
b) Produit les artefacts suivants :
- System Sequence Diagram (SSD): oprations systme avec prconditions et post-conditions

6 ETAPES dun processus de

dveloppement (suite)
6)

Logiciel fourni :
A chaque itration dimplmentation, un incrment est fourni au
client.
Exemples dincrment :
- un cran de cration de devis
- association de lcran la cration dun plan mdia

Limplication du client doit tre forte

Seront rgulirement runis : analyste + dveloppeur + client
NB : Recommandation : un artefact doit tre produit sur maximum
3 semaines (sinon prvoir de plus petits artefacts)

193

Travaux pratiques

Utilisation du logiciel Rational Rose Enterprise 2003

Rational Rose est le Leader Mondial en outil de Modlisation UML, c'est aussi l'un
des plus coteux. Rational propose par ailleurs de nombreux outil pour faciliter la
gestion des projets de dveloppement. Rational a par ailleurs pass un accord avec la
Socit Ensemble pour distribuer le Rose Link qui procure une liaison bidirectionnelle
synchronise entre un modle UML de Rose et un code Java ou Delphi par exemple.
Avec cette combinaison le reverse engineering partir d'une application Java ou
Delphi est possible. Rose Link Java est disponible pour Borland, JBuilder, Visual Caf,
Oracle JDeveloper, & IBM's VisualAge.

194

Utilisation du logiciel Microsoft Office Visio 2003

(cf. http://www.microsoft.com/france/office/visio/decouvrez.mspx )

Cf. les 6 TPs proposs sur http://www.gramme.be/infopb/

coursSL/analyse/TP

Avec de lexprience
Etre

comptent en UML, cest comprendre ce

que chaque type de diagramme peut offrir et
savoir quand il faut lutiliser. Souvent, un
concept pourra tre exprim au moyen de
plusieurs diagrammes; lutilisateur
expriment dUML saura utiliser le(s) plus
adapt(s) sa modlisation.

195