Analyse, Spcification

et Modlisation
avec UML
Bertrand LE GAL
Filire RSI 2me anne
ENSEIRB 2006/07

Plan du cours
I. Retour sur le flot de conception logiciel
II. Introduction UML
III. Le diagramme des cas dutilisation
IV. Les diagrammes de classes
V. Implmentation des modles
VI. Les diagrammes de squence et de collaboration
VII. Les diagrammes dtats-transitions
VIII. Les diagrammes de dploiement
VII. Conclusion
2

Retour sur le ot de
Conception
Bertrand LE GAL
Filire RSI 2me anne - ENSEIRB
2006/2007

Les causes courantes des checs de projets

Mauvaise comprhension des besoins des utilisateurs

finaux.

Incapacit grer les modifications des exigences des

clients au cours du dveloppement.

Les modules composant le projet ne fonctionnent pas

ensemble (mauvaises interfaces)

Code source du logiciel difficile maintenir ou faire

voluer

Logiciel de mauvaise qualit (beaucoup danomalies de

conception / excution)
4

Lidal pour la gestion dun projet !

1. Bien comprendre les besoins, les demandes et les exigences
des utilisateurs finaux.

2. Bonne communication avec le client pour valider certains

choix et vrification de ltape (1).

3. Tester et valider chaque phase de la conception pour ne pas

dcouvrir des problmes plus tard.

4. Traiter au plus tt les problmes.

5. Matriser la complexit et augmenter la rutilisation.
6. Dfinir une architecture robuste.
7. Faciliter le travail en quipe.
5

Les 7 bonnes pratiques

1. Dveloppement itratif,
2. Dveloppement base de composants
centr sur larchitecture,
3. Pilotage du dveloppement par les risques,
4. Gestion des exigences,
5. Matrise des modifications,
6. Evaluation continue de la qualit,
7. Modlisation visuelles.
6

1 - Le dveloppement itratif

Cette mthode est base

sur de petites tapes
(lmentaires).

A
D

Chaque tape produit des

retours et des adaptations
si ncessaire.

E
F

Autres dnominations
Dveloppement en spiral
Dveloppement volutif

C
7

2. Dveloppement bas sur les composants

Validation de larchitecture
logicielle lors des premires
itrations :
Dveloppement bas sur des

IP du commerce,
Rutilisation prfre au

redveloppement,

Tester larchitecture au plus

tt mme si elle nest pas
fonctionnellement complte.

3. Pilotage par les risques

Analyser les risques potentiels au plus tt (dbut de la

conception) :
Les regrouper et les hirarchiser,
Travailler en priorit sur les risques critiques,

Cela concerne les risques techniques, ainsi que :

Les risques lis aux clients,
Les risques lis au domaine applicatif,
Les risques lis lorganisation du projet,

Smantique
Un risque est un vnement redout dont l'occurrence est plus ou moins

prvisible et qui aura des rpercussions sur le projet.

Un problme est un risque qui sest rvl.
9

4. Les exigences du client

Smantique
Une exigence est une condition laquelle le systme doit

satisfaire ou une capacit dont il doit faire preuve.

Les exigences peuvent tre :

Fonctionnelles
Elles dcrivent ce que le systme doit savoir faire,

Non fonctionnelles
Qualit des services,
Temps de rponse, temps de traitement,
Scurit au fonctionnement,
IHM adapte aux utilisateurs.

10

5. Les demandes de changement

Smantique
Une demande de changement est une requte visant modifier

un artefact ou un processus.

Il faut dans ce cas indiquer dans la documentation, la

nature du changement, sa cause et ses impacts sur la
solution propose.

Il existe 2 types de changements

La demande dvolution
Nouvelle caractristique du systme ou modifications dune existante

Le rapport danomalie
11

6. Evaluation constante de la qualit

Il a t prouv que lidentification des erreurs de

conception au plus tt permet de gagner de largent
(ou den perdre moins)
Ratio 10 100 !

Les problmes de qualit sont souvent les causes

principales des dpassements de dlais,

Les phases de test, de vrification et de correction

consomment environ 70% du temps total dun projet !

60% des problmes existent dj dj lors de la

conception de lapplication.
12

Pourquoi utiliser la modlisation visuelle ?

On doit pouvoir mmoriser nos penses et les

communiquer en utilisant des langages visuels et
schmatiques.
Rseaux de Ptri,
Grafcet
UML, etc.

Avantages de ces approches

Les langages visuels sont naturels et faciles comprendre

(non relatifs un langage de communication).

On estime que 50% du cerveau est impliqu dans le processus

visuel.
13

Introduction UML
Bertrand LE GAL
Filire RSI 2me anne - ENSEIRB
2006/2007

UML est un langage standard conu pour permettre

aux concepteurs dlaborer les plans des logiciels
quils doivent dvelopper.

On se sert du langage UML pour:

Visualiser,
Spcifier,
Construire,
Documenter,
Communiquer (travailler plusieurs),
15

UML est un langage

Ce langage possde un vocabulaire et des rgles qui

permettent de combiner les mots afin de communiquer.

La modlisation permet de comprendre le systme,

Tous les modles sont lis les uns avec les autres afin
de reprsenter le systme et les interactions entre les
blocs lmentaires.

Le vocabulaire et les rgles dcriture rgissent la

manire de construire et de lire les modles correctement
mis en forme.
Aucune dcision dimplmentation.
16

UML, un langage pour visualiser

Pour certains dveloppeurs, il y existe un lien direct entre

une ide et son code dimplmentation.
Utilisation dun modle de reprsentation mental.

Problme dans le partage de ces modles avec dautres

personnes,
Risques dincomprhension, dincertitudes...
Chaque organisation et/ou personne possde son propre langage

(difficult dintgration)

UML permet de rsoudre les problmatiques du partage de

linformation de manire visuelle.
17

UML, un langage pour visualiser

UML est bien plus quun assemblage de symboles

graphiques !
Chaque symbole graphique possde sa smantique propre

(signification universelle).
Un modle peut tre crit par un concepteur et compris pas un

autre sans ambigut...

Une automatisation par outil peut ainsi tre mise en place pour

traiter certaines informations.

UML est un mta-langage de modlisation permettant

dunifier les modles utiliss dans les mthodes de
dveloppement (raffinement).
18

UML, un langage pour spcier

Dans le cadre dUML, spcifier signifie construire

sans ambigut,

UML offre la possibilit de spcifier le

comportement de lapplication de manire formelle,
Rflexion sur des modles formels,
Approche indpendante du langage objet

d'implmentation (C++, Java, etc.).

UML nest pas une mthode mais une notation qui

laisse la libert de conception.
19

UML, un langage pour documenter

Lors du dveloppement dun produit, on ralise des

choix :
Architecture dimplmentation,
Besoins identifis,
Code source du projet,
Planning de dveloppement,
Les plans et les jeux de test, etc.

UML permet de raliser la dfinition et la

documentation de ces taches.
20

Les domaines dutilisation de UML

UML est employ dans lensemble des secteurs du

dveloppement informatique :
Systmes dinformation,
Tlcommunication, dfense,
Transport, aronautique, arospatial,
Domaines scientifiques,

Mais pas seulement : on peut modliser des

comportement mcaniques, humain, etc.
Structure dun systme de sant / judiciaire, etc.
21

Les briques de base dUML

Dans le langage UML, il existe 3 types de briques

de base :
1. Les lments

Ce sont les abstractions essentielles au modle.

2. Les relations

Les relations expriment les liens existants entre les diffrents

lments.

3. Les diagrammes

Les diagrammes comprennent des ensembles dlments dignes

d'intrt.

22

Il existe 4 types dlments dans UML

Ce sont les lments de base qui vont permettre la

dfinition par la suite des modles.
1. Les lments structurels,
2. Les lments comportementaux,
3. Les lments de regroupement,
4. Les lments dannotation.

23

Les lments structurels

Les lments structurels sont les lments les plus

statiques dUML, il en existe 7 types distincts :
1. Les classes,
2. Les interfaces,
3. Les collaborations,
4. Les cas dutilisation,
5. Les classes actives,
6. Les composants,
7. Les noeuds.

24

Les lments comportementaux

Les lments comportementaux reprsentent les

parties dynamiques des modles,

Ils permettent de dfinir le comportement du

modle dans le temps et lespace,

Il en existe 2 types fondamentaux :

1. Les interactions,
2. Les automates tats finis.

25

Les lments de regroupement

Les lments de regroupement reprsentent les

parties organisationnelles des modles UML,

Ce sont les boites dans lesquelles un modle peut

tre dcompos,

Il existe un seul type dlment de regroupement :

le package

26

Les lments dannotation

Les modles dannotation reprsentent les parties

explicatives des modles UML.

Ce sont les commentaires qui vont tre ajouts aux

modles afin :
Dexpliquer un choix,
Dcrire le fonctionnement,
Faire une remarque,
Dtailler une hypothse
Spcifier une contrainte dimplmentation
27

Les relations dans UML

Afin dexprimer les liens interconnectant les

diffrents lments des modles, 4 relations de base
ont t dfinies :
1. La dpendance,
2. La gnralisation
3. Lassociation,
4. La ralisation,

28

Les diagrammes en UML

Un systme est un ensemble de sous-systmes organiss
pour atteindre un objectif et dcrit laide de modles.
Un sous-systme est un regroupement dlments , dont
certains spcifient le comportement propos par les autres
lments contenus.
Un modle est une abstraction complte et cohrente dun
systme permettant den faciliter la comprhension.
- Modlisation des parties structurelles (statique)
- Modlisation du comportement (dynamique)
29

Voiture

Roues

Carosserie

Moteur

... ... ... ... ...

Pompe

Radiateur

Bloc Moteur

... ... ... ... ...

30

Les diagrammes avec UML

Un diagramme est une reprsentation visuelle de

lensemble des lments qui constituent le systme.
Ils servent visualiser un systme sous diffrents angles

(utilisateur, administrateur par ex.)

Dans les systmes complexes, un diagramme ne

fourni quune vue partielle du systme.
Lensemble des diagrammes abouts permet dobtenir

une vue globale du systme concevoir.

Chaque diagramme va permettre de modliser ou

spcifier une vue (spcificit) du systme concevoir.

31

Les diagrammes dans UML : 9 types

Les diagrammes statiques

1.
2.
3.
4.

Diagramme de classes,
Diagramme dobjets,
Diagramme de composants,
Diagramme de dploiement,

Les diagrammes dynamiques

5. Diagramme de cas dutilisation,
6.
7.
8.
9.

Diagramme de squences,
Diagramme de collaboration,
Diagramme dtats-transitions,
Diagramme dactivits.
32

Les diagrammes structurels

Les diagrammes de classes

Ils reprsentent lensemble des classes, des interfaces et

des collaborations ainsi que leurs relations.

Les diagrammes les plus utiliss dans une approche de

dveloppement objets.

Les diagrammes dobjets

Ils reprsentent un ensemble dobjets (instances de

classes) avec leurs relations,

Similaire aux diagrammes de classes, mais avec des

dtails rels et des prototypes.

33

Les diagrammes structurels

Les diagrammes de composants

Ils sont apparents aux diagrammes de classes.
Un composant correspond gnralement une ou

plusieurs classe, interfaces ou collaboration.

Les diagrammes de dploiements

Ils sont apparents aux diagrammes de composants.
Un noeud englobe gnralement un ou plusieurs

composants.
34

Les diagrammes comportementaux

Les diagrammes de cas dutilisation

Organisent les comportements du systme.
Reprsentation des acteurs et de leurs relations avec

lapplication.

Les diagrammes de squences

Centrs sur lordre chronologique des messages.
Il modlisent chronologiquement les messages changs par

les objets du systme (sous-systme).

Ce sont les 2 modles les plus employs (modlisation

dynamique)
35

Les diagrammes comportementaux

Les diagrammes de collaboration

Centrs sur lorganisation structurelle des objets qui communiquent

(envoie & rception des messages).

Mise en vidence des liens existants entre les objets.

Les diagrammes tats-transitions

Centr sur le changement dtat du systme en fonction des

vnements.
Modlisation sous forme dun automate tats-finis (tat, action,
transition).

Les diagrammes dactivits

Centrs sur le flot de contrle dune activit sur une autre.
36

Diagramme de cas
dutilisation
Bertrand LE GAL
Filire RSI 2me anne - ENSEIRB
2006/2007

Introduction aux cas dutilisation

Les cas dutilisation servent modliser le comportement

dynamique dun systme (sous systme).

Les comportements diffrents dun systme sont

reprsent sous forme de cas dutilisation,
On ne se proccupe pas de limplmentation du systme, juste

des services quil doit rendre aux utilisateurs,

Donnes directement extraites du cahier des charges,

Un cas dutilisation dcrit un ensemble de squences dans

lequel chaque squence reprsente les interactions entre
l'extrieur du systme (acteurs) et le systme lui mme.
38

Introduction

Lexpression des cas dutilisation permet de savoir

quels sont les services que doit implmenter le
systme et qui il doit les rendre !

Les cas dutilisation se composent :

Dacteurs externes au systme (personnes, capteurs,

autres applications ... ),

Du systme en lui mme et des services quil doit rendre,
Des relations qui relient les acteurs aux services qui leurs

sont rendus,
39

Cas dutilisation, les acteurs

Un acteur est une personne ou une chose
qui va rentrer en interaction avec le
systme concevoir !

Dtecteur
de fum

Enseignant
Secrtaire
Systme de
gestion des
badges

Etudiant

Administrateur

40

Cas dutilisation, relations entre acteurs

Secretaire

Fontionnaire

Enseignant

Matre de
confrences

acteurs

gnralisation
(hritage)

Chercheur

nom
Une secrtaire est une fonctionnaire, tout comme les enseignants et les
chercheurs. Un matre de confrence est un fonctionnaire qui fait un travail
denseignant et de chercheur la fois.
41

Cas dutilisation, les actions

Ensemble
du systme

Systme tudier

nom de
l'action

Enregistrer
la
commande

Envoyer la
commande

Un cas dutilisation saisit le

comportement attendu du
systme sans que lon prcise
comment cela est ralis.

Identifier
l'utilisateur

Grer les
commandes

Collaboration

Ralisation
La collaboration permet de raffiner
la vue implmentation du systme
en factorisant les points
communs.
42

Cas dutilisation, Relations entre actions

Passer
commande
urgente
<extensions>
(fixer priorit)

relation d'extension

Passer
commande

<utilisations>

Relation d'inclusion

Valider
l'utilisateur

<utilisations>

Suivre la
commande

La relation dinclusion est faite pour

viter la rptition des actions en
factorisant les services rendus. Cela
revient dlguer une partie des actions.

La relation dextension permet

de modifier lgrement le
comportement de base.

Vrifier le
mot de
passe

Scanner
rtinien

gnralisation

La relation de gnralisation
modlise un hritage du
comportement de base afin
de laffiner.

43

An de dessiner un cas dutilisation...

Identifier lensemble des acteurs possibles qui vont

interagir avec lapplication,
Identifier tous les acteurs,
Les factoriser sous forme de groupes,

Prendre en considration les besoins de tous les

utilisateurs
Le regrouper les besoins communs laide des relations

dinclusion, de gnralisation et dextension,

44

Exemple pdagogique : lENSEIRB

LENSEIRB dsire automatiser le processus d'inscription

des tudiants, en voici le cahier des charges :
Le responsable des filires tablit au dbut de chaque semestre le

programme des cours

Chaque tudiant doit slectionner 4 cours obligatoires et 2 cours

optionnels par semestre.

Lorsquun tudiant sinscrit, le systme de facturation est averti et

gnre immdiatement la facture.

Les enseignants utilisent ces informations pour consulter leur

service.
Les tudiants peuvent consulter leur emploi du temps en fonction

des cours quils ont choisis.

45

Exemple, Identication des acteurs

4 acteurs existent dans

notre cahier des charges :
1. Ltudiant,
2. Lenseignant,
3. Le systme de facturation,
4. Le directeur des lires,
Ce sont les seules personnes
qui interagissent avec le
systme (selon le cahier des
charges).

Enseignant

Etudiant

Service de
facturation

Directeur

46

Exemple, Identication des fonctions

Un cas dutilisation est un motif de comportement

intrinsque au systme
Chaque cas dutilisation est une squence de transactions

connectes, effectues par un dialogue entre un acteur et le systme.

Identification des besoins propres au acteurs

Chef de service - maintenir le programme des tudes.
Enseignant - demander un tableau de service.
Etudiant - tablir un emploi du temps.
Systme de facturation - recevoir les informations de facturation du

systme dinscription.
47

Les cas dutilisations, solution

Systme
Etablir un
emploi du
temps
Etudiant

S'inscrire

Enseignant

Demander
un tableau
de service
Grer les
filire
Directeur

Service de
facturation

48

Bien identier les cas dutilisation

Un cas dutilisation
Ensemble dactions produisant un rsultat observable pour un

acteur particulier,

Chaque cas dutilisation candidat,

Vrifier quil fournit une valeur ajoute
Vrifier lexistence dun vnement externe le produisant,
Dcrire le cas dutilisation succinctement,

Attention au niveau de granularit

Ne pas descendre trop bas,
Limiter le nombre de niveau (<20)
49

Documenter les cas dutilisation

Pour chaque cas dutilisation, il faut :

Exprimer ce que fourni lutilisateur au systme et ce quil

reoit en retour aprs excution,

Il faut aussi penser dtailler les hypothses ralises (pr-

requis et les post-conditions)

Lexpression des transactions entre le systme et

l'utilisateur sera dtaill par dautres modles :
Diagrammes de squences,
Diagrammes dactivit, etc.
50

Scnario dun cas dutilisation

Demande dun tableau de service (enseignant)

1. Lenseignant se prsente devant un terminal,
2. Le systme affiche un message d'accueil,
Description
simplifie
3. Lenseignant demande un relev dheures,
4. Le systme lui demande de s'authentifier,
5. Lenseignant s'authentifie (login et mot de passe),
6. Le systme affiche les informations lcran,
7. Lenseignant prcise quil a termin sa consultation et quil
dsire se dconnecter,

8. Le systme effectue la requte et retourne lcran daccueil.

51

Scnario dun cas dutilisation

Demande dun tableau de service (enseignant)

Pr-conditions
Lenseignant doit tre inscrit luniversit
Lenseignant doit connatre ses identifiants
Post-condition

(si lopration sest bien droule)

Lenseignant a pris connaissance des heures de

cours quil a donn

52

Diagrammes de classes
Bertrand LE GAL
Filire RSI 2me anne - ENSEIRB
2006/2007

Les diagrammes de classes

Le contenu dun diagramme de classes

Des classes,
Des interfaces,
Des collaborations,
Des relations (dpendances, associations, gnralisation),

Le diagramme de classes peut tre dfini diffrents

niveaux dabstraction
Point de vue conceptuel,
Point de vue des spcifications
Point de vue implmentation
54

Dnition dune classe

Une classe est la description lmentaire dun ensemble

dobjets qui partagent des attributs et des mthodes communs.

La dfinition des attributs et des mthodes nest pas

obligatoire :
Les attributs et les mthodes sont trop nombreux pour tre

reprsents dans la majorit des cas...

On indique alors les responsabilits de la classe sous forme de

texte (ce quelle doit implmenter comme service).

On peut ds la dfinition dune classe prciser les droits

daccs aux mthodes et aux attributs (+, -, #)

55

Exemple de modlisation dune classe

Nom de la
classe

Attributs
Vecteur
taille : int;
nb_lments : int = 0
tableau : int*
Vecteur()
add(donne : int)
remove(position : int)
get(position : int) : int
set(position, valeur : int)
..................

Mthodes

56

Introduction aux relations

Les roues, le moteur, les portes, la carrosserie font

partie du vocabulaire de construction dune voiture
mais ils nexistent pas de manire indpendantes.

En UML, la manire dont les lments sont

interconnects entre eux (logiquement ou
structurellement) est modlis sous forme de
relation.

57

Les relations : la dpendance

La dpendance tablit une relation dutilisation entre 2

entits dun mme diagramme.

La plus part du temps il sagit dune dpendance

dutilisation,
Argument dune mthode par exemple,
On parle alors de relation dutilisation,

Cela permet didentifier implications possibles des

modifications apporter dans une entit
Changement du comportement dune des classe par exemple.
58

Les relations : la dpendance

Voiture
taille : int;
type : string
acclrer()
freiner(position : int)
dmarrer(c : Clef)

Dpendance

La classe Voiture dpend

pour son utilisation de la
classe Clef

Clef

59

Les relations : la gnralisation

La gnralisation modlise la notion dhritage qui existe

dans les langages objets
La gnralisation correspond la notion est une sorte de,
Modlisation des relations parents / enfants,

Cela implique que les entits issues dune gnralisation

sont utilisables partout ou leur classe mre peut l'tre (mais
pas linverse)
Gnralisation (classe, classe) ou (classe, interface),

Cette relation est modlise par une flche pointant sur la

classe mre,
60

Les relations : la gnralisation

Forme
origine
move()
resize()
show()

Rectangle
coin : Point

Carr

Cercle
coin : Point

Polygone
point : List
show()

Les entits (classes) Rectangle, Cercle et

Polygone sont des classe filles qui
hritent de la classe mre Forme. De la
mme manire, lentit Carr hrite de
lentit Rectangle.
61

Les relations : lassociation

Les relations d'association permettent de modliser un

lien structurel entre 2 lments du modle.
Si le lien joint 2 classes alors cela signifie quil existe une

relation de navigabilit entre ces 2 classes,

4 dcorations permettent de spcifier plus finement le

lien entre les objets :
Le nom : dcrire la nature de la relation entre les objets,
La direction : lever l'ambigut sur le nom,
Les rles : indiquer le rle spcifique de chacune des classes

dans lassociation,
La cardinalit : spcifie le nombre dlments affects.
62

Les relations : lassociation

Association
Personne

Entreprise

Nom

Personne

Direction
Travaille pour

Entreprise

Travaille pour

Personne
Employ

Entreprise

Employeur

Roles
63

Les relations : lagrgation

Dans lassociation, les entits se trouvent au mme

niveau hirarchique.

Dans l'agrgation, il existe une relation hirarchique

entre les entits,

Lagrgation rpond la question se compose de et

modlise une notion de possession,
Notion de tout et de parties,

Se note comme une association avec un losange du cot

du tout.
64

Les relations : lagrgation

Tout

Voiture
4

Agrgation
1

Partie

Roue

65

Conclusion sur les relations

Les relations doivent tre spcifies pour toutes les classes

qui interagissent entre elles,

Les relations sont des liens statiques entre les diffrentes

entits (classes),
Les relations apparaissent quasi-exclusivement dans les diagrammes

de classes,

Il existe 2 autres types de relations utiliss dans la

modlisation dynamique :
Les liens : flux permettant le transfert de messages entre objets.
Les transitions : utiliss dans la modlisation des machines

tats finis.
66

Spcication des commentaires (Notes)

Lors des phases de modlisation et de spcification,

il est ncessaire de documenter ses modles :
Contraintes matrielles,
Contraintes de performance,
Choix techniques raliss,
Rfrences dautres documents,
Explications techniques, etc.

Dans le langage UML, il existe une smantique

pour les commentaires.
67

Modlisation des commentaires

Voiture

Ne pas oublier
d'intgrer la roue
de secours.

Roue

Regarder le fichier
rparation.doc pour
l'implmentation de la
rparation de la roue
aprs crevaison.

68

Diagramme de classes, exemple

Nous allons maintenant essayer de modliser une

entreprise laide dun diagramme de classes :
Une entreprise est compose de plusieurs services, dans

ces services officie un certain nombre de personnes.

Dans les locaux de lentreprise se trouvent des bureaux

utiliss par les employs, chaque bureau porte un numro

et possde un numro de tlphone.
Les employs sont reconnus laide de leur nom et de

leur numro personnel. Chaque employ possde un

statut dans lentreprise.
69

Diagramme de classes, exemple

Entreprise

gnralisation
(est compos de)

1
*

Name
1
chaine : string
getName():string
setName(string)

*
*

Service
nom : Name
show()

Personnel
effectif : int
getNombre() : int

Bureau
adresse : string
telephone : int
show()

Agrgation
(emploie)

1...*

Personne
nom : Name
ID : int
titre : string
email: string
ObtenirPhoto()
ObtenirEMail()

Sige

1...*

gnralisation
(contient)

70

Diagramme de classes, exemple 2

Nous allons nous attacher modliser une

universit :
Luniversit est compose dtudiants qui suivent des

cours dans les filires de leur choix.

Ces cours sont dispenss par des enseignants qui peuvent

tre responsable des filires.

Les cours sont dispenss dans au moins une filire et

peuvent tre mutualits avec dautres.

A partir de l, raliser le diagrammes de classes

modlisant luniversit.
71

Correction de lexemple 2

Universit

Filire

tudiants

Cours

Enseignant

Voici les 5 entits de base qui constituent

luniversit que nous devons modliser
72

Correction de lexemple 2
possde
1

agrgation
(responsable)

0...1

1...*

Universit

Filire

affecter

est membre

1...*
1...*

1...*

tudiants

Cours
1...*

1...*

0...1

Enseignant

assiste

prodigue

73

Correction de lexemple 2
Universit
nom : string
adresse : string
telephone : int
ajouterEtudiant()
supprEtudiant()
listeEtudiants()
ajouterFilire()
supprFilire()
listeFilires()

possde

Universit
1...* nom : string
AjouterEnseignant()
supprEnseignant()
listeEnseignant()
1

agrgation
(responsable)

affecter

est membre
1...*

Cours
nom : string
1 identifiant : int

assiste

1...*
0...1

1...*

1...*

Etudiant
nom : string
identifiant : int

0...1

1...*

Enseignant
nom : string
1 prnom : string
lireNom() 0...1

prodigue

74

Exemple de travail itratif sur le modle

Permanent
numroBureau
spcialit
nombreCours
nom
numroScu

Vacataire
nombreVacation
nombreCours
spcialit
nom
numroScu

75

Exemple de travail itratif sur le modle

Enseignant
spcialit
nombreCours
nom
numroScu

Permanent
numroBureau

Vacataire
nombreVacation

76

Exemple de travail itratif sur le modle

Boulanger
nombreClient
adresseMagasin
nom
numroScu

Vendeur
anciennet
nomStand
nom
numroScu

Enseignant
spcialit
nombreCours
nom
numroScu

Permanent
numroBureau

Vacataire
nombreVacation

77

Exemple de travail itratif sur le modle

Personne
nom
numroScu

Boulanger
nombreClient
adresseMagasin

Vendeur
anciennet
nomStand

Enseignant
spcialit
nombreCours

Permanent
numroBureau

Vacataire
nombreVacation

78

Diagramme de classes
Implmentation des modles
Bertrand LE GAL
Filire RSI 2me anne - ENSEIRB
2006/2007

Et aprs les modles, que faiton ?

Les diagrammes permettent de spcifier de manire

claire, les classes et les relations existantes entre elles.
Gnration de code source partir du modle,
Les modles ne sont pas spcifiques un langage (choix

la gnration => 1 modle plusieurs implmentations

possibles suivant les contraintes)

A partir de tout diagramme UML, il est possible de

remonter vers le cahier des charges
Les lments du modle ont une smantique propre et

unique
80

Et aprs les modles que faiton ?

Une fois que lon a ralis lensemble des

diagrammes de classe, on va traduire les modles
dans un langage objet :
Indpendance du modle vis--vis du langage utilis pour

l'implmentation.
Nous utiliserons ici du C++

Chaque type dentit et de relation possde une

implmentation particulire,
Pas d'ambigut possible.
81

Transformation du modle au code source

Catalogue

class Catalogue{

// ... ... ...
};

Personne

class Personne {

// ... ... ...
};

82

Implmentation de la gnralisation

Catalogue

namespace Catalogue
{

// ... ... ...
};

83

Implmentation de la ralisation

Catalogue
nom : Name
dateCration : Date

Personne
nom : string
prnom : string
dateNaissance : string
ageMajorit: string : int = 18;

class Catalogue {
private:
string nom;

DateTime dateCreation;

// ... ... ...
}
class Personne {
private:
string nom;
string prnom;
protected:

DateTime dateNaissance;
private:
static int ageMajorite = 18;
}

84

Implmentation de la dpendance

Personne
- nom : string
- prnom : string
# dateNaissance : string
- ageMajorit: string : int = 18;
+ calculDurePret() : int
+ setAgeMajorit( int )
+ getAge(): int

class Personne {
private:

string nom;
string prnom;

static int ageMajorite = 18;
protected:
DateTime dateNaissance;
public:
int CalculerDureePret();
static void SetAgeMajorite(int
aMaj) {


// ... ... ...
}
public int GetAge() {


// ... ... ...
}
}

85

Implmentation de la composition (agrgation)

Personne
- nom : string
- prnom : string
- age : int

Adhrent
- ID : int

class Personne {
// ... ... ...
}
class Adhrent : Personne {
private int iD;
}

86

Implmentation dune association

<<Interface>>
Empruntable

<<Interface>>
Imprimable

Emprunter()
Retourner()

Imprimer()

Livre
titre : string
auteur : string
isbn : ISBN
Emprunter()
Retourner()
Imprimer()

class Livre : public Imprimable :

public Empruntable {
private:

string titre;
string auteur;
ISBN isbn;
public:

void Imprimer(){


// ... ... ...

}
void Emprunter(){


// ... ... ...

}
void Retourner(){


// ... ... ...

}
}

87

ClasseA

ClasseB
1

ClasseA

ClasseB

ClasseA

* {order}

ClasseB

public class A1 {
private:
ClasseB leB;
// ... ... ...
}
public class A2 {
private:
ClasseB[] lesB;
// ... ... ...
}
public class A3 {
private:
ArrayList lesB;

// ... ... ...
lesB = = new ArrayList();
}

88

Homme

0...1

mari

poux

0...1
Femme

class Homme {
private:

Femme pouse;

// ... ... ...
}
class Femme {
private:

Homme mari;

// ... ... ...
}

89

Personne

0...*

employ

0...*

employeur
Socit

Emploi
titre : string
salaire : double

class Emploi {
private:
string titre;
double salaire;
Personne employ;
Socit employeur ;

// ... ... ...
}

90

Les diagrammes de squence

et de collaboration
Bertrand LE GAL
Filire RSI 2me anne - ENSEIRB
2006/2007

Les diagrammes de squence

Mise en vidence de laspect temporel des

traitement (ordre chronologique de ralisation),

Mise en vidence des objets et des messages

changs par les entits interagissant avec et/ou
dans le systme,

La modlisation est base sur laffichage des objets

participant la squence et lordre des messages
et des actions associes.
92

Dnition de la smantique du diagramme

Les diagrammes de squence permettent de modliser

les interactions entre les objets :
Communications synchrones (flches pleines),
Communications asynchrones (flches pointills),
Les donnes transmises entre les objets (annotation des

flches),

Ils permettent aussi de connatre pour chaque objet :

Ses dates de cration et de destruction,
Sa dure de vie, si la cration est externe au diagramme (ligne

verticale en pointills).
93

Exemple de lascenseur
Objets
anonymes
Usager

Assenceur

Porte

Appel extrieur
(n tage)
Dplacement

Message
Demande ouverture
des portes

Stimulis

Portes ouvertes

94

Objets / Entits

Client
E-Mail

Serveur
SMTP
Cration

Socket

setServeur(name)

volution
du temps

ConnexionOK
Send(email)

DataSendOK

Connexion
ConnexionOK
SendData(data)
Close()

Destroy

Lignes de vie
95

Priodes
d'activit

Le diagramme de collaboration

Mise en vidence de lorganisation des objets qui

vont collaborer pour effectuer une interaction.
On reprsente les objets qui vont intervenir (les sommets),
On modlise les liens qui vont modliser les

communications entre les objets (les arcs),

On annote les liens laide des informations qui vont tre

changes entre les entits,

Visualisation claire du flot de contrle dans le

contexte de l'organisation structurelle.
96

Le diagramme de collaboration

2 niveaux de reprsentation (dabstraction)

Le niveau spcification
Dfinition des classes et de leurs rles,

Le niveau instance
Dfinition des objets et des messages changs,

97

Modlisation dun graphe de rle

/Locataire :
Personne

Objet

+ Habitant

+ Habitation
/Maison :
Logement

+ Loueur

/Propritaire :
Personne

+ Adresse
:Lieu

98

Le diagramme de collaboration

La modlisation temporelle est en partie masque,

Utilisation de la numrotation des squences pour

ordonner les traitements raliss,

Contrairement au diagramme de squence, certaines

informations ne sont pas reprsentes :
On ne modlise pas le ligne de vie des objets,
On ne modlise pas les temps dactivit des objets,

Par contre on modlise explicitement les liens qui

existent entre les diffrents objets.
99

Squence

Client E-Mail

Objet

1. Cration
2. setServeur(name)
4. SendMail(email)
6. Destruction

3. ConnexionOK
5. DataSendOK

2.1. Connexion
4.1. SendData
5. Close
Socket

Serveur
2.2. ConnexionOK

Message
Lien
100

Utilisation de ces diagrammes

Ces diagrammes sont utiliss pour modliser les

comportements dynamiques dun systme,
Modliser le fonctionnement dun sous systme,
Possibilit de joindre ces diagrammes aux cas

dutilisation afin de spcifier un scnario.

Il est possible de rajouter des contraintes sur les

diagrammes :
Contraintes temporelles (dure d'excution),
Formaliser le flot de contrle : ajouter des pr/post-

conditions.
101

Equivalence entre les diagrammes

Z
X

A
B
1.1 - A
1.2 - C
C
1.1.1 - B
Y

102

Diagrammes dtatstransitions
Bertrand LE GAL
Filire RSI 2me anne - ENSEIRB
2006/2007

La recherche des tats

Ltat dun objet est li aux

valeurs de ses attributs et de
ses interactions avec les
autres objets,

Il est ncessaire de conserver

les tats signicatifs,

La rponse dun vnement

un stimuli dpend :
Du stimuli reu par lobjet,
De ltat dans lequel se trouve

Livre
estPrt
estRserv

Livre
libre

Livre
pret

Livre
rserv

lobjet.

104

Rgles lies au diagramme dtats

Chaque transition (passage dun tat un autre) est

provoqu par un vnement,

Une transition na pas de dure (utilisation possible

dtats de temporisation),

La dure dun tat est lintervalle qui scoule entre

l'vnement dentre et celui de dpart.

105

Diagramme dtats dun livre

Achat

Etat final

Destruction
(poubelle)

Etat initial
Livre
libre

Evnements
(condition)

Emprunt
Restitution

Livre
pret

Rservation
Libration

Emprunt

Livre
rserv

Etats
106

Smantique lie la reprsentation

Etat n-1

Nom de l'tat
entrer / actions a raliser en rentrant dans l'tat
faire / activits faire durant l'tat
... ... ... ... ... ... ... ... ... ... ... ... ... ...
sortir / / actions a raliser en sortant de l'tat

Etat n+1

107

Et la conception dans tout

cela ...
Bertrand LE GAL
Filire RSI 2me anne - ENSEIRB
2006/2007

Et la conception du systme ...

La phase de conception a pour objectif de chercher comment est

implment le systme,
Lanalyse vise quant elle identifier ce qui doit tre fait (et
non comment).
Lapproche est hirarchique sattachant dabord au grandes
parties du systme et leurs interactions, puis raffinement
progressif,
Prise en compte des contraintes exprimes la conception
(langage, BDD, temps dexec, processeurs, priphriques, etc.).
Cest une tape ou on va faire intervenir des spcialistes de
chaque discipline en fonction des technologies mises en oeuvre.

109

Diagrammes de dploiement
Bertrand LE GAL
Filire RSI 2me anne - ENSEIRB
2006/2007

Le diagramme de dploiement

Ce modle dfinit le diagramme de larchitecture

matrielle du systme ou de lapplication,

Il reprsente les diffrentes ressources matrielles

disposition : processeurs et priphriques et la
rpartition de lapplication sur le systme
htrogne,

Il prcise aussi les liens de communication existants

entre ces diffrentes ressources.
111

Le diagramme de dploiement
Systme
d'acquisition

Bluetooth

Processeur
distributeur

Ecran

USB

Imprimante

Rseau 100Mo
Supercalculateur

Rseau 1Go

FireWire

Systme
d'acquisition

Serveur de
donnes

112

Conclusion
Bertrand LE GAL
Filire RSI 2me anne - ENSEIRB
2006/2007

Conclusions sur UML

Langage permettant d'apprhender la ralisation dun

systme informatique complexe

Diagrammes qui permettent daider la rflexion, de

permettre la discussion sur des bases normalises et
formalises (clients, dveloppeurs)

Pas de solution unique mais un ensemble de solutions plus

ou moins acceptables
Contraintes clients (performances et fonctionnalits),
Architectures logicielles et matrielles disposition,

Des itrations successives du flot permettent daboutir une

solution.
114

Bibliographie

Modlisation avec UML, Robert Ogor, ENST

Bretagne, Mai 2003.

UML : Unified Modeling Language, Mireille

Blay-Fornarino, ESSI, Sophia Antipolis

UML, Martin Fowler, Collection Le tout en

poche, CampusPress

Le Guide de lutilisateur UML, Grady Booch and

al., Edition Eyrolles.
115