(Livre-Technique - Com) UML 2 Analyse Et Conception

UML 2
DVELOPPEMENT
ANALYSE ET CONCEPTION
TUDES
Mise en uvre guide

avec tudes de cas
Joseph Gabay
David Gabay
UML 2
Mise en uvre guide

avec tudes de cas
Joseph Gabay
Directeur de projet informatique au CNRS
Charg de cours luniversit de Paris-Dauphine
David Gabay
Chef de projet chez Cap Gemini
Toutes les marques cites dans cet ouvrage sont des
marques dposes par leurs propritaires respectifs.
Illustration de couverture : Mountain, DAJ, Hokkaido

Source : gettyimages
Dunod, Paris, 2008

ISBN 978-2-10-053567-5
Tables des matires
Avant-propos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IX
Chapitre 1 Concepts de lapproche objet et prsentation dUML 2 . . . . . . . . 1
1.1 Concepts de lapproche objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Objet et classe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 Encapsulation et interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.3 Association et agrgation entre les classes. . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.4 Gnralisation et spcialisation de classe . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.5 Polymorphisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.6 Persistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.7 Avantages du dveloppement laide des langages objet . . . . . . . . . . . . . . . 6
1.2 Prsentation gnrale dUML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2 Structuration de la prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.3 Rgles gnrales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.4 Prsentation gnrale des diagrammes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.5 Schma densemble des treize diagrammes dUML 2 . . . . . . . . . . . . . . . . . 14
Chapitre 2 Les diagrammes structurels (ou statiques). . . . . . . . . . . . . . . . . . . 17
2.1 Diagramme de classe (DCL) et diagramme dobjet (DOB) . . . . . . . . . . . . . . 17

2.1.1 Objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.2 Classe, attribut et opration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
IV UML2 analyse et conception
2.1.3 Association, multiplicit, navigabilit et contraintes . . . . . . . . . . . . . . . . . . 23

2.1.4 Agrgation et composition entre classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1.5 Association qualifie, dpendance et classe dinterface . . . . . . . . . . . . . . . . 30
2.1.6 Gnralisation et spcialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.1.7 Strotype de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.1.8 Exercices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.2 Diagramme de composant (DCP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.2.1 Composant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.2.2 Les deux types de reprsentation et exemples . . . . . . . . . . . . . . . . . . . . . . . 46
2.3 Diagramme de dploiement (DPL). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.3.1 Nud. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.3.2 Artefact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.3.3 Spcification de dploiement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.3.4 Liens entre un artefact et les autres lments du diagramme . . . . . . . . . . . . 52
2.3.5 Reprsentation et exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.4 Diagramme de paquetage (DPA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2.4.1 Paquetage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2.4.2 Dpendance entre paquetages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.5 Diagramme de structure composite (DSC). . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.5.1 Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Chapitre 3 Les diagrammes comportementaux . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.1 Diagramme des cas dutilisation (DCU). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.1.1 Prsentation gnrale et concepts de base . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.1.2 Reprsentation du diagramme des cas dutilisation . . . . . . . . . . . . . . . . . . . 63
3.1.3 Relations entre cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.1.4 Description textuelle dun cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.1.5 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.2 Diagramme dtat-transition (DET) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.2.2 Reprsentation du diagramme dtat-transition dun objet . . . . . . . . . . . . . . 73
3.2.3 Complments sur le diagramme dtat-transition . . . . . . . . . . . . . . . . . . . . 75
3.2.4 Exercices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Tables des matires V
3.3 Diagramme dactivit (DAC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

3.3.2 Reprsentation du diagramme dactivit . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.3.3 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
3.4 Diagramme de squence (DSE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
3.4.2 Oprations particulires. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
3.4.3 Fragment dinteraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
3.4.4 Autre utilisation du diagramme de squence. . . . . . . . . . . . . . . . . . . . . . . . 101
3.4.5 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
3.5 Diagramme de communication (DCO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
3.5.2 Formalisme et exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
3.5.3 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
3.6 Diagramme global dinteraction (DGI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
3.6.2 Reprsentation et exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
3.7 Diagramme de temps (DTP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Chapitre 4 Dmarche de dveloppement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

4.1 Prsentation dUP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
4.2 Les principes dUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.2.1 Processus guid par les cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.2.2 Processus itratif et incrmental. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.2.3 Processus centr sur larchitecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.2.4 Processus orient par la rduction des risques . . . . . . . . . . . . . . . . . . . . . . . 113
4.3 Les concepts et les deux dimensions du processus UP . . . . . . . . . . . . . . . . . . 113
4.3.1 Dfinition des principaux concepts et schma densemble . . . . . . . . . . . . . . 113
4.3.2 Phases et itrations du processus (aspect dynamique) . . . . . . . . . . . . . . . . . 114
4.3.3 Activits du processus (aspect statique) . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.4 Les principaux apports de RUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
4.4.1 Les bonnes pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
4.4.2 Les phases et les activits du processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
VI UML2 analyse et conception
4.5 Dmarche de dveloppement UP7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

4.5.1 Prsentation gnrale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
4.5.2 Description des activits (fiche guide par sous-activit) . . . . . . . . . . . . . . . . 128
4.5.3 Complments sur la conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Chapitre 5 tude de cas n 1 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

5.1 nonc du cas ALLOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
5.2 Modlisation mtier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
5.2.1 laboration du schma de contexte du domaine dtude (FG1). . . . . . . . . . 150
5.2.2 laboration du diagramme dactivit (FG2). . . . . . . . . . . . . . . . . . . . . . . . 150
5.2.3 laboration du diagramme de classe mtier (FG3) . . . . . . . . . . . . . . . . . . . 151
5.2.4 Extrait des documents de cadrage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
5.3 Exigences fonctionnelles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
5.3.1 laboration du diagramme des cas dutilisation systme (FG4). . . . . . . . . . 153
5.3.2 laboration du diagramme de squence systme (FG5) . . . . . . . . . . . . . . . 155
5.3.3 laboration du schma de navigation gnrale (FG6). . . . . . . . . . . . . . . . . 158
5.4 Analyse des cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
5.4.1 laboration du diagramme des cas dutilisation (FG7) . . . . . . . . . . . . . . . . 159
5.4.2 Description des cas dutilisation (FG8, FG9, FG11, FG12) . . . . . . . . . . . 159
5.5 Synthse de lanalyse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Chapitre 6 tude de cas n 2 Analyse et conception . . . . . . . . . . . . . . . . . . . . 175
6.1 nonc du cas Gestion activit et frais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

6.2 Modlisation mtier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
6.2.1 laboration du schma de contexte du domaine dtude (FG1). . . . . . . . . . 176
6.2.2 laboration du diagramme dactivit (FG2). . . . . . . . . . . . . . . . . . . . . . . . 176
6.2.3 laboration du diagramme de classe mtier (FG3) . . . . . . . . . . . . . . . . . . . 177
6.3 Exigences fonctionnelles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
6.3.1 laboration du diagramme des cas dutilisation systme (FG4). . . . . . . . . . 181
6.3.2 laboration des diagrammes de squence systme (FG5) . . . . . . . . . . . . . . 182
6.3.3 laboration du schma de navigation gnrale (FG6). . . . . . . . . . . . . . . . . 184
6.4 Analyse des cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
6.4.1 laboration du diagramme des cas dutilisation (FG7) . . . . . . . . . . . . . . . . 185
6.4.2 Description des cas dutilisation (FG8, FG9, FG11, FG12) . . . . . . . . . . . 186
Tables des matires VII
6.5 Synthse de lanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

6.5.1 laboration du diagramme de classe rcapitulatif (FG13) . . . . . . . . . . . . . 202
6.5.2 laboration de la matrice de validation (FG14) . . . . . . . . . . . . . . . . . . . . . 204
6.6 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
6.6.1 Ralisation des choix techniques et laboration des diagrammes techniques
(FG15, FG16, FG17) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
6.6.2 laboration du diagramme de paquetage (FG18). . . . . . . . . . . . . . . . . . . . 216
Annexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
A. Rcapitulatif des concepts dUML 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
B. Rcapitulatif de la dmarche UP7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Avant-propos
UML, une volution majeure dans le domaine des mthodes

UML compte dj une dizaine dannes dexistence. lchelle dun courant
mthodologique, cest encore une dure relativement courte puisque lon estime
quun cycle de dveloppement dune mthode de cette envergure stale sur une
priode de vingt trente ans, ce qui a t le cas par exemple pour Merise.
Mais lacclration du renouvellement des technologies conjugue avec la pres-
sion conomique et concurrentielle qui sexerce sur les entreprises, obligent les
acteurs du monde informatique produire des solutions de plus en plus rapidement
dans un contexte damlioration continue de la qualit et de la performance des sys-
tmes dinformation.
Notons aussi quInternet a t un vecteur favorisant le dveloppement de trs
nombreuses applications dont une grande partie utilise des solutions base de lan-
gage de programmation objet comme Java, C++ ou C#.
UML a apport tout naturellement le support mthodologique qui manquait
tous les concepteurs et dveloppeurs qui voulaient formaliser lanalyse et la concep-
tion technique de leur logiciel.
UML sest donc impose en tant que langage graphique de modlisation puisque
non seulement ce langage rpond un vritable besoin mais en outre il est devenu
un standard de fait puisquil sappuie sur une norme trs structurante.
Rendons tout de mme hommage aux trois pres fondateurs dUML que sont
James Rumbaugh, Ivar Jacobson et Grady Booch qui ont t ds le dbut des
annes 90 des rfrences dans le monde des mthodes de dveloppement objets. Les
ouvrages quils ont crits lpoque sont l pour en tmoigner : [Rumbaugh1991],
[Booch1994] et [Jacobson1992].
X UML2 analyse et conception
Cest grce un premier niveau de travail de fond men en commun par ces trois
compres quest ne en 1995 la mthode dite unifie qui a t ensuite consacre par
lOMG (Object Management Group) en 1997 avec la diffusion de la premire version
de la norme : UML V1.1.
Prcisons aussi que les trois auteurs lorigine dUML ont poursuivi leur mission
dexplication et dillustration des diffrentes versions successives dUML en publiant
des ouvrages de rfrence comme [Jacobson2000b] et [Rumbaugh2004].
Il nous semble important de souligner le rle majeur jou par lOMG. En effet,
cet organisme international de normalisation a en charge non seulement la norme
UML mais aussi dautres rflexions mthodologiques comme lapproche MDA
(Model Driven Architecture) qui pousse encore plus loin les limites de lautomatisa-
tion de la production du logiciel.
Ainsi nous pouvons imaginer que nous arriverons bien un jour disposer dune
mthode de conception et de dveloppement standardise couvrant tout le cycle de
fabrication dun logiciel en permettant une production fortement automatise de la
programmation.
Mais soyons ralistes, cela demandera notre avis probablement plusieurs dcen-
nies tant donn les difficults qui restent traiter et la complexit des niveaux
dabstraction quil faut arriver modliser.
Cest loccasion pour nous de lancer un petit avertissement aux concepteurs
dUML travaillant lOMG pour leur dire que certes lobjectif vis reprsente un
norme challenge pour toute la profession informatique, mais cela ne doit pas se tra-
duire par une plus grande lourdeur et complexit du contenu de cette norme. En
effet, cest le ressenti que nous commenons avoir en observant les versions succes-
sives de la norme qui se caractrise aujourdhui par plusieurs centaines de pages lire
et un nombre sans cesse croissant de concepts assimiler associs une reprsenta-
tion graphique qui devient aussi de plus en plus dense.
Positionnement de louvrage
Notre tude des nombreux ouvrages dj publis sur UML 2, nous a permis de cons-
tater quil en existait dj un certain nombre qui stait attach une prsentation
relativement exhaustive et dtaille de la norme, comme par exemple dans
[Muller2000] et [Fowler2004a] ou encore dautres plus synthtiques comme
[Scott2004], [Fowler2004b], [Barbier2005] et [Blaha2002].
Cependant, nous navons pas trouv de livres traitant la fois laspect norma-
tif dUML 2 et la dmarche dlaboration des diagrammes couvrant lanalyse et la
conception des systmes dinformation.
Nous avons donc dcid de rpondre ce besoin en essayant de traiter le plus
efficacement possible les treize diagrammes dUML 2 conformment la norme et
en accompagnant le lecteur dans un apprentissage progressif fond sur de nombreux
exemples, des exercices corrigs et de vritables tudes de cas se rapprochant de pro-
jets rels dentreprise.
Avant-propos XI
Nous proposons donc dans un mme ouvrage dune part laspect thorique des
concepts dUML 2 et leur reprsentation graphique et dautre part une dmarche de
mise en uvre illustre par des fiches guides pour les activits danalyse et de con-
ception mener dans le cadre des dveloppements des systmes dinformation (SI).
En rsum nous nous sommes fix trois objectifs en ralisant ce livre :
prsenter les treize diagrammes dUML 2 en essayant de concilier au mieux le
respect strict de la norme avec une application centre sur les systmes
dinformation des entreprises.
illustrer la modlisation laide des diagrammes dUML 2 en sappuyant sur
des exemples et des exercices adapts au contexte professionnel donc aux
attentes des concepteurs et dveloppeurs dapplication.
proposer une dmarche de mise en uvre dUML 2 qui est fonde sur les
processus standard du dveloppement itratif et incrmental et qui prenne en
compte notre propre exprience de praticiens de la mthode. Cette dmarche
fait lobjet dune description prcise des activits avec notamment des fiches
guides et une mise en application dans deux tudes de cas consquentes.
Notre double comptence de professionnel de la conception et du dveloppe-

ment des systmes dinformation en entreprise, et denseignant universitaire dans le
domaine des mthodes des SI nous a permis de faire bnficier louvrage de notre
grande pratique (dix annes) dUML, et de lexprience tire de nombreuses annes
denseignements dUML dispenss en milieu universitaire (MIAGE, MASTER,
IUT, BTS...).
En tant quenseignant dUML nous avons pu, au fil des annes, affiner une
dmarche progressive dapprentissage. Cest ainsi que pour les points dlicats, nous
avons toujours recherch une approche pragmatique sappuyant sur des exemples
pour accompagner la prsentation thorique des concepts.
En tant que professionnel, les enseignements dune longue exprience de la pra-
tique des mthodes auprs des quipes de dveloppement de projets ont t particu-
lirement prcieux. De plus, le point de vue des utilisateurs a t aussi un indicateur
pertinent pour ajuster au mieux la pratique de ces mthodes.
Enfin nous restons intimement convaincus que lexpos thorique dune
mthode doit tre rduit lessentiel et quau contraire une large place doit tre don-
ne lapplication ; cest ainsi quen matire dapprentissage dune mthode, il faut
bien entendu apprendre pour pratiquer mais aussi et peut-tre plus que dans
nimporte quel autre domaine : pratiquer pour mieux apprendre.
Organisation de louvrage
Louvrage est structur en six chapitres :
Le chapitre 1 dcrit les concepts de lapproche objet et propose une premire
prsentation dUML 2 en mettant laccent sur les dernires volutions.
XII UML2 analyse et conception
Le chapitre 2 traite les six diagrammes structurels : diagramme de classe,

diagramme dobjet, diagramme de composant, diagramme de dploiement,
diagramme de paquetage et diagramme de structure composite.
Le chapitre 3 est lui consacr aux sept diagrammes comportementaux :
diagramme des cas dutilisation, diagramme dactivit, diagramme dtat-tran-
sition, diagramme de squence, diagramme de communication, diagramme
global dinteraction et diagramme de temps.
Des exemples et exercices corrigs sont associs la prsentation de la plupart des

13 diagrammes. Nous avons aussi utilis, en tant que fil conducteur, un mme exercice
Locagite pour les diagrammes les plus structurants (classe, cas dutilisation et squence).
Le chapitre 4 porte sur la dmarche que nous proposons de mettre en uvre

avec UML 2 en vue de traiter lanalyse et la conception de systme dinforma-
tion. Cette dmarche prend appui sur le processus unifi UP (Unified Process)
et intgre le fruit de lexprience des auteurs dans la conduite de projets rels
mens en entreprise.
Nous avons privilgi une prsentation sous forme de fiches guides pour
couvrir la dmarche danalyse et de conception.
Les chapitres 5 et 6 sont consacrs aux tudes de cas afin dillustrer, sur des
sujets plus consquents que de simples exercices, le langage de formalisation
dUML 2 dune part et lapplication de la dmarche propose dans cet ouvrage
dautre part.
La premire tude de cas (chapitre 5) est essentiellement ddie ltape
danalyse, tandis que la seconde (chapitre 6) couvre les tapes danalyse et de
conception.
En rsum, le lecteur pourra tout dabord acqurir les connaissances ncessaires lappren-
tissage dUML 2 (chapitres 1 3) et ensuite sexercer la mise en pratique grce la dmar-
che propose et aux deux tudes de cas couvrant lensemble des phases danalyse et de
conception (chapitres 4 6).
qui sadresse ce livre ?

Cet ouvrage de synthse sur les concepts, la reprsentation graphique des
diagrammes dUML 2 et la mise en uvre guide en analyse et conception sadresse :
aux tudiants de premier et second cycle universitaire qui veulent sinitier
UML 2 et matriser tous les concepts ;
tous ceux qui connaissent dj UML et qui dsirent comprendre les change-
ments apports par UML 2 ;
tous les professionnels, concepteurs et dveloppeurs, qui souhaitent mieux
matriser UML 2 et acqurir une dmarche pratique de mise en uvre.
Avant-propos XIII
Remerciements
Quil nous soit permis de remercier tous ceux qui ont apport une contribution dans
la ralisation de cet ouvrage.
Plus particulirement, nous voudrions remercier Jacques LAVIELLE pour les
changes fructueux sur les concepts et la dmarche et pour toutes les discussions que
nous avons eues autour des enseignements dUML luniversit Paris-Dauphine.
Enfin, nous adressons tous nos remerciements Nicolas ZENOU pour son aide
prcieuse et efficace dans la relecture attentive quil a bien voulu consacrer cet
ouvrage.
1
Concepts de lapproche objet
et prsentation dUML 2
1.1 CONCEPTS DE LAPPROCHE OBJET
Aujourdhui lapproche objet occupe une place prpondrante dans le gnie logiciel.
En effet, ces dernires annes nous avons assist tout dabord une utilisation plus
large des langages de programmation objet de rfrence comme C++, C# et Java et
ensuite lintroduction des concepts objet dans dautres langages comme par
exemple VB.NET, Perl et mme Cobol. Le dveloppement trs important dapplica-
tions lies Internet constitue une des principales explications de ce phnomne
sans prcdent alors que lon aurait pu sattendre un dmarrage plus prcoce de ce
changement compte tenu de lexistence ds le dbut des annes 80 des premiers
langages objet tel que C++.
notre avis les deux vnements majeurs qui ont marqu cette volution se sont
produits la fin des annes 90 avec larrive de Java en 1995 et dUML en 1997.
Notre objectif est donc de prsenter lessentiel des concepts objet qui nous
paraissent ncessaires une bonne comprhension dUML. Les concepts qui nous
semblent importants bien matriser sont les suivants :
objet et classe,
encapsulation et interface,
association et agrgation de classes,
gnralisation et spcialisation de classe,
polymorphisme,
persistance.
2 Chapitre 1. Concepts de lapproche objet et prsentation dUML 2
Nous nutiliserons pas, par contre dans ce chapitre, de formalisme particulier de

reprsentation puisque nous ne voulons pas ajouter un formalisme de plus celui
dj dfini dans UML.
Nous prcisons que nous nous limitons volontairement, dans le cadre de cet
ouvrage, une prsentation gnrale des principaux concepts de lapproche objet.
Le lecteur qui dsire approfondir ses connaissances dans ce domaine pourra se re-
porter aux nombreux ouvrages traitant en dtail lapproche objet comme
[Meyer2000]et [Bersini2004].
1.1.1 Objet et classe

Concept dobjet
Un objet reprsente une entit du monde rel (ou du monde virtuel pour les objets
immatriels) qui se caractrise par un ensemble de proprits (attributs), des tats
significatifs et un comportement.
Ltat dun objet correspond aux valeurs de tous ses attributs un instant donn.
Les proprits sont dfinies dans la classe dappartenance de lobjet. Le comporte-
ment dun objet est caractris par lensemble des oprations quil peut excuter en
raction aux messages provenant des autres objets. Les oprations sont dfinies dans
la classe dappartenance de lobjet.
Exemple
Considrons lemploy Durand, n 1245, embauch en tant quingnieur travaillant
sur le site N.
Cet objet est caractris par la liste de ses attributs et son tat est reprsent par
les valeurs de ses attributs :
n employ : 1245,
nom : Durand,
qualification : ingnieur,
lieu de travail : site N.
Son comportement est caractris par les oprations quil peut excuter. Dans
notre cas nous pouvons avoir les oprations suivantes :
entrer dans lorganisme,
changer de qualification,
changer de lieu de travail,
sortir de lorganisme.
Concept de classe
Une classe est labstraction dun ensemble dobjets qui possdent une structure iden-
tique (liste des attributs) et un mme comportement (liste des oprations).
1.1 Concepts de lapproche objet 3
Un objet est une instance dune et une seule classe. Une classe abstraite est une
classe qui na pas dinstance. Les concepts de classe et dobjet sont interdpendants.
Exemple
Considrons la classe Employ qui reprsente lensemble des employs dune entre-
prise. La description de la classe Employ comportera les lments suivants :
Nom de classe : Employ.
Attributs :
numro,
nom,
qualification,
site de travail.
Oprations :
engager un employ,
consulter un employ,
modifier un employ,
dpart dun employ.
1.1.2 Encapsulation et interface

Par rapport lapproche classique, lapproche objet se caractrise par le regroupe-
ment dans une mme classe de la description de la structure des attributs et de la
description des oprations. Ce regroupement des deux descriptions porte le nom
dencapsulation donnes-traitements.
Plus prcisment, les donnes ne sont accessibles qu partir doprations dfinies
dans la classe. Le principe dencapsulation renforce lautonomie et lindpendance
de chaque classe et donne une potentialit accrue de dfinition de classe rutilisable.
Lensemble des oprations dune classe rendu visible aux autres classes porte le nom
dinterface. Le schma densemble du principe de lencapsulation est prsent la
figure 1.1.
1.1.3 Association et agrgation entre les classes

Lassociation reprsente une relation entre plusieurs classes. Elle correspond
labstraction des liens qui existent entre les objets dans le monde rel. Les multipli-
cits (ou cardinalits) et les rles des objets participant aux relations compltent la
description dune association. Les exemples dassociations sont donns directement
dans les diagrammes de classe dUML.
Lagrgation est une forme particulire dassociation entre plusieurs classes. Elle
exprime le fait quune classe est compose dune ou plusieurs autres classes. La rela-
tion composant-compos ou la relation structurelle reprsentant lorganigramme
dune entreprise sont des exemples types de la relation dagrgation.
CLASSE N
Traitements
Accs I 1- Oprations accessibles Donnes :
aux donnes N - opration 1 liste
via linterface T
E - opration 2 des attributs
(partie visible
R - opration 3
de la classe) F
A
C
E
2- Oprations non accessibles

- opration A
- opration B

Figure 1.1 Schma de principe de lencapsulation
1.1.4 Gnralisation et spcialisation de classe

La gnralisation de classes consiste factoriser dans une classe, appele super-
classe, les attributs et/ou oprations des classes considres. Applique lensemble
des classes, elle permet de raliser une hirarchie des classes.
La spcialisation reprsente la dmarche inverse de la gnralisation puisquelle
consiste crer partir dune classe, plusieurs classes spcialises.
Chaque nouvelle classe cre est dite spcialise puisquelle comporte en plus des
attributs ou oprations de la super-classe (disponibles par hritage) des attributs ou
oprations qui lui sont propres.
Une classe spcialise porte aussi le nom de sous-classe. La spcialisation de
classe se construit en deux temps : dabord par hritage des oprations et des attributs
dune super-classe et ensuite par ajout doprations et/ou dattributs spcifiques la
sous-classe.
La gnralisation-spcialisation est un des mcanismes les plus importants de
lapproche objet qui facilite la rutilisation des classes.
1.1.5 Polymorphisme
Le polymorphisme est la capacit donne une mme opration de sexcuter diff-
remment suivant le contexte de la classe o elle se trouve.
Ainsi une opration dfinie dans une super-classe peut sexcuter de manire dif-
frente selon la sous-classe o elle est hrite.
1.1 Concepts de lapproche objet 5
En fait lors de lexcution, lappel de lopration va automatiquement dclencher

lexcution de lopration de la sous-classe concerne. Dans le droulement de lex-
cution de lopration de la sous-classe, il est possible de faire appel lopration de la
super-classe qui contient en gnral la partie commune applicable aux deux sous-
classes.
Exemple
Soit la classe Employ et ses deux sous-classes Cadre et NonCadre.
Nom de classe : Employ.
Attributs :
numro,
nom,
salaire de base.
Oprations : calculSalaire( ).
Nom de la sous-classe : Cadre.
Attributs : niveau dencadrement.
Nom de la sous-classe : NonCadre.
Attributs : niveau de spcialisation.
Le principe de calcul du salaire tant de calculer pour chaque type demploy une
prime spcifique en fonction soit du niveau dencadrement, soit du niveau de spcia-
lisation selon le type demploy.
Voyons maintenant comment se ralise lapplication du polymorphisme lors de
lexcution des oprations.
Dans cet exemple, lorsque lon appelle lopration calculSalaire( ), cest lopra-
tion de sous-classe Cadre ou celle de la sous-classe NonCadre qui est en fait active
selon lobjet concern. Lopration de la sous-classe fait en gnral appel explicite-
ment lopration calculSalaire( ) de la super-classe pour bnficier des traitements
communs aux cadres et non cadres et ensuite il y aura poursuite du traitement spci-
fique la sous-classe.
1.1.6 Persistance
La persistance est la proprit donne un objet de continuer exister aprs la fin
de lexcution du programme qui la cr.
Par dfaut dans lapproche objet, aucun objet nest persistant. Les modles dcri-
vent le systme en excution en mmoire centrale et ne tiennent pas compte a priori
de ltat du systme qui doit tre stock sur disque.
La gestion de la mmoire incombe au programmeur avec notamment le problme
de la libration des espaces.
1.1.7 Avantages du dveloppement laide des langages objet

Par rapport une approche fonctionnelle associe un dveloppement classique
men laide de langages procduraux, on est en droit de sinterroger sur les avan-
tages quapporte rellement le dveloppement laide dun langage objet comme par
exemple C++, C# ou Java.
En fait, deux avantages prpondrants sont mis en gnral en avant lorsque lon
choisit une approche objet :
La modularit Par construction, tant donn que lon conoit des classes
reprsentant une entit de taille limite en donnes et en oprations, il est
plus ais de construire des systmes modulables que si lon labore une seule
base de donnes dune part et un seul logiciel dautre part.
La rutilisabilit La dfinition dun systme laide de classe ayant chacune
la responsabilit dun sous-ensemble de donnes et des oprations associes
favorise fortement la potentialit de trouver des classes rutilisables. La ruti-
lisation de classe se ralise soit sur le plan mtier lintrieur dune mme
entreprise dans des applications diffrentes, soit sur le plan technique
lchelle de tous les dveloppements raliss laide dun mme langage. Sur
ce dernier aspect, cest toute lapproche du dveloppement par composant qui
est en jeu.
Au-del de ces deux avantages majeurs et compte tenu de la plus grande modula-
rit dans la construction dune application laide dobjets, la maintenance lmen-
taire de chaque classe est en soi plus simple raliser que celle dun logiciel unique
traitant toutes les donnes dun systme. Il importe bien entendu dans lapproche
objet de construire son systme en veillant minimiser le nombre de relations entre
classes.
1.2 PRSENTATION GNRALE DUML
1.2.1 Historique
Regardons tout dabord ce qui sest pass au dbut des annes 90. Par rapport la
cinquantaine de mthodes danalyse et de conception objet qui existaient au dbut
des annes 90, seulement trois dentre elles se sont dtaches nettement au bout de
quelques annes. En effet, la volont de converger vers une mthode unifie tait
dj bien relle et cest pour cette raison que les mthodes OMT, BOOCH et OOSE
se sont dmarques des autres.
OMT (Object Modeling Technique) de James Rumbaugh et BOOCH de
Grady Booch ont t les deux mthodes les plus diffuses en France durant les
annes 90. Par ailleurs, OOSE de Ivar Jacobson sest aussi impose dans le monde
objet pour la partie formalisation des besoins.
1.2 Prsentation gnrale dUML 7
Pour aller plus loin dans le rapprochement, James Rumbaugh et Grady Booch se
sont retrouvs au sein de la socit Rational Software et ont t ensuite rejoints par
Ivar Jacobson en se donnant comme objectif de fusionner leur mthode et crer
UML (Unified Methode Language).
Il est important de noter que contrairement ce qui avait t envisag au dpart,
le processus de dveloppement a t sorti du champ couvert par le projet de norme.
UML est donc une norme du langage de modlisation objet qui a t publie,
dans sa premire version, en novembre 1997 par lOMG (Object Management
Group), instance de normalisation internationale du domaine de lobjet.
En quelques annes, UML sest impose comme standard utiliser en tant que
langage de modlisation objet.
Aujourdhui, en cette fin de la premire dcennie des annes 2000, nous avons
dj une dizaine dannes de recul sur lenseignement et la pratique dUML en entre-
prise.
Les grandes tapes de la diffusion dUML peuvent se rsumer comme suit :

1994-1996 : rapprochement des mthodes OMT, BOOCH et OOSE et naissance de la
premire version dUML.
23 novembre 1997 : version 1.1 dUML adopte par lOMG.
1998-1999 : sortie des versions 1.2 1.3 dUML.
2000-2001 : sortie des dernires versions suivantes 1.x.
2002-2003 : prparation de la V2.
10 octobre 2004 : sortie de la V2.1.
5 fvrier 2007 : sortie de la V2.1.1 (version de rfrence du prsent ouvrage).
1.2.2 Structuration de la prsentation

Nous proposons au lecteur une prsentation dtaille dUML 2 en privilgiant
notamment dans les exemples et les tudes de cas le contexte dutilisation des
systmes dinformation. Le lecteur pourra, sil le souhaite ensuite, approfondir sa
connaissance dUML en consultant directement la norme de rfrence disponible
via internet [OMG2007].
La prsentation dUML ralise dans le prsent ouvrage se veut synthtique et
pragmatique. Nous navons pas voulu couvrir tous les dtails de la norme qui repr-
sente aujourdhui un volume de prs de 700 pages.
Nous avons, tout dabord, pris le parti dillustrer systmatiquement les concepts
prsents et la notation dUML par des exemples concrets les plus proches possible
du domaine de la gestion des entreprises. Ensuite nous donnons, pour les diagram-
mes les plus structurants dUML des exercices densemble corrigs et nous traitons
aussi un exercice de synthse (Locagite) qui nous sert de fil conducteur et dillustra-
tion tout au long de louvrage.
La prsentation de la dmarche que nous proposons UP7 sappuie fortement sur

le processus UP (Unified Process).
Les deux tudes de cas traits dans cet ouvrage sont loccasion de voir comment
les principaux concepts et la notation dUML peuvent sappliquer sur des domaines
dtude plus importants que ceux des exercices et sont loccasion de concrtiser la
dmarche dapplication dUML que nous proposons.
Nous sommes convaincus que cette prsentation pragmatique dUML, associe
aux deux tudes de cas, doit constituer une aide efficace tous ceux qui veulent soit
sinitier UML soit approfondir leur matrise dUML en particulier sur toutes les
nouveauts apportes par UML 2.
1.2.3 Rgles gnrales

Afin dassurer un bon niveau de cohrence et dhomognit sur lensemble des
modles, UML propose dune part un certain nombre de rgles dcriture ou de
reprsentations graphiques normalises et dautre part des mcanismes ou des
concepts communs applicables lensemble des diagrammes. Certains lments,
comme les strotypes, sont spcifiquement prvus pour assurer une relle capacit
dadaptation et dvolution de la notation notamment pour prendre en compte les
particularits des diffrentes situations modliser. Les principaux lments gn-
raux dUML que nous prsentons sont : le strotype, la valeur marque, la note, la
contrainte, et la relation de dpendance.
En outre UML propose un mta-modle de tous les concepts et notations asso-
cies utiliss dans les treize diagrammes du langage de modlisation.
Mta-modle
Le langage de modlisation UML respecte un certain nombre de rgles sur les
concepts manipuls (classes, attributs, oprations, paquetages) ainsi que sur la
syntaxe dcriture et le formalisme de reprsentation graphique. Lensemble de ces
rgles constitue en soi un langage de modlisation qui a fait lobjet dun mta-
modle UML. Lintrt de disposer dun mta-modle UML permet de bien
matriser la structure dUML et de faciliter son volution.
Cette approche a t gnralise par lOMG en normalisant la reprsentation des
mta-modles par la dfinition en 1997 dun mta mta-modle dfini dans le MOF
(Meta-Object Facility). Le MOF reprsente ainsi un super langage de dfinition des
mta-modles.
Plus globalement, le MOF se retrouve au sommet dune architecture de descrip-
tion quatre niveaux :
M3, niveau du MOF ;
M2, niveau des mta-modles (UML est un des mta-modles) ;
M1, constitu par les modles (les diagrammes dUML sont des instances de
ce niveau) ;
M0, constitu par les instances (les ralisations de diagrammes pour une situa-
tion donne sont des instances de ce niveau).
Le mta-modle dUML est compltement dcrit dans la norme.
Strotype
Un strotype constitue un moyen de classer les lments de la modlisation. Un
certain nombre de strotypes sont dj dfinis dans UML (voir annexe C de la
norme), mais dautres valeurs de strotypes peuvent tre ajoutes si cela est nces-
saire soit lvolution gnrale dUML, soit la prise en compte de situations parti-
culires propres aux entreprises.
Les strotypes peuvent sappliquer nimporte quel concept dUML. Nous nous
intresserons dans cet ouvrage un certain nombre dentre eux que nous prsente-
rons au niveau des diagrammes lorsque leur utilisation nous paratra pertinente.
En particulier, dans le diagramme de classe, le strotype permet de considrer de
nouveaux types de classe. Cette possibilit dextension pour les classes, se dfinit
donc au niveau mta-classe.
Formalisme et exemple
Le nom du strotype est indiqu entre guillemets. Un acteur peut tre vu comme un
strotype particulier dune classe appele acteur. Lexemple (fig. 1.2) montre une
classe Client strotype comme acteur .
Client
acteur
Figure 1.2 Exemple dune classe strotype
Valeur marque
UML permet dindiquer des valeurs particulires au niveau des lments de modli-
sation et en particulier pour les attributs de classe. Une valeur marque se dfinit au
niveau mta-attribut.
La valeur marque est mise entre accolades avec indication du nom et de la valeur :
{persistance : string} si lon veut ajouter ce type dattribut dans une classe.
Profil
Afin de donner la possibilit de spcialiser chaque application dUML son propre
contexte, UML propose de dfinir un profil dutilisation caractris principalement
par la liste des strotypes, la liste des valeurs marques et les contraintes spcifies
pour un projet donn.
Note
Une note correspond un commentaire explicatif dun lment dUML.
La figure 1.3 montre le formalisme et un exemple de la reprsentation dune note.
Commentaire Ce modle
reprsente la vue
des gestionnaires
Figure 1.3 Formalisme et exemple dutilisation dune note
Contrainte
Une contrainte est une note ayant une valeur smantique particulire pour un
lment de la modlisation. Une contrainte scrit entre accolades {}. Dans le cas o
la contrainte concerne deux classes ou plus, celle-ci sinscrit lintrieur dune note.
Premire forme dcriture dune contrainte : {ceci est une contrainte}.
Deuxime forme dcriture : lintrieur dune note (fig. 1.4).
Dans UML, un langage spcifique dexpression de contraintes est disponible ;

cest le langage OCL (Object Contraint Language). Ce langage nest pas dcrit dans
le prsent ouvrage.
Parking Rsident
possder
Immeuble
{le parking
dun rsident se trouve
dans limmeuble rsider
du rsident}
Figure 1.4 Exemple dutilisation dune contrainte

(sans reprsentation des multiplicits)
1.2.4 Prsentation gnrale des diagrammes

UML dans sa version 2 propose treize diagrammes qui peuvent tre utiliss dans la
description dun systme. Ces diagrammes sont regroups dans deux grands ensem-
bles.
Les diagrammes structurels Ces diagrammes, au nombre de six, ont vocation
reprsenter laspect statique dun systme (classes, objets, composants).
Diagramme de classe Ce diagramme reprsente la description statique du
systme en intgrant dans chaque classe la partie ddie aux donnes et
celle consacre aux traitements. Cest le diagramme pivot de lensemble de
la modlisation dun systme.
Diagramme dobjet Le diagramme dobjet permet la reprsentation dins-
tances des classes et des liens entre instances.
Diagramme de composant (modifi dans UML 2) Ce diagramme reprsente
les diffrents constituants du logiciel au niveau de limplmentation dun
systme.
Diagramme de dploiement (modifi dans UML 2) Ce diagramme dcrit
larchitecture technique dun systme avec une vue centre sur la rpartition
des composants dans la configuration dexploitation.
Diagramme de paquetage (nouveau dans UML 2) Ce diagramme donne une
vue densemble du systme structur en paquetage. Chaque paquetage repr-
sente un ensemble homogne dlments du systme (classes, compo-
sants).
Diagramme de structure composite (nouveau dans UML 2) Ce diagramme
permet de dcrire la structure interne dun ensemble complexe compos par
exemple de classes ou dobjets et de composants techniques. Ce diagramme
met aussi laccent sur les liens entre les sous-ensembles qui collaborent.
Les diagrammes de comportement Ces diagrammes reprsentent la partie
dynamique dun systme ragissant aux vnements et permettant de produire
les rsultats attendus par les utilisateurs. Sept diagrammes sont proposs par
UML :
Diagramme des cas dutilisation Ce diagramme est destin reprsenter les
besoins des utilisateurs par rapport au systme. Il constitue un des diagram-
mes les plus structurants dans lanalyse dun systme.
Diagramme dtat-transition (machine dtat) Ce diagramme montre les dif-
frents tats des objets en raction aux vnements.
Diagramme dactivits (modifi dans UML 2) Ce diagramme donne une
vision des enchanements des activits propres une opration ou un cas
dutilisation. Il permet aussi de reprsenter les flots de contrle et les flots
de donnes.
Diagramme de squence (modifi dans UML 2) Ce diagramme permet de
dcrire les scnarios de chaque cas dutilisation en mettant laccent sur la
chronologie des oprations en interaction avec les objets.
Diagramme de communication (anciennement appel collaboration) Ce dia-

gramme est une autre reprsentation des scnarios des cas dutilisation qui
met plus laccent sur les objets et les messages changs.
Diagramme global dinteraction (nouveau dans UML 2) Ce diagramme four-
nit une vue gnrale des interactions dcrites dans le diagramme de
squence et des flots de contrle dcrits dans le diagramme dactivits.
Diagramme de temps (nouveau dans UML 2) Ce diagramme permet de
reprsenter les tats et les interactions dobjets dans un contexte o le temps
a une forte influence sur le comportement du systme grer.
Aujourdhui UML 2 dcrit les concepts et le formalisme de ces treize diagrammes
mais ne propose pas de dmarche de construction couvrant lanalyse et la concep-
tion dun systme. Ce qui a pour consquence par exemple de ne pas disposer dune
vision des interactions entre les diagrammes.
Afin de donner un premier aperu des principaux diagrammes tant sur laspect du
formalisme que sur leur usage, nous proposons titre introductif un petit exemple
trs simple.
Considrons une nouvelle socit de formation qui souhaite dvelopper un pre-
mier niveau de site web dans lequel elle prsente succinctement les formations pro-
poses et enregistre en ligne les demandes de catalogue.
Nous pouvons ds ce stade de lanalyse reprsenter le diagramme des cas dutilisa-
tion (fig. 1.5).
Consulter catalogue
Internaute
Cas
dutilisation
Commander catalogue
Client
Figure 1.5 Exemple de diagramme des cas dutilisation
Le diagramme de classe (fig. 1.6) va nous permettre de dcrire les concepts mani-
puls, savoir : Client, Catalogue et Formation.
Client
Catalogue
numClient commander
nomClient dateCatalogue
+crer( ) +crer( )
+consulter( ) +consulter( )
Formation
attributs codeFormation
intitulFormation
descriptionFormation
contenir
oprations
+ajouterFormation( )
+consulterFormation( )
Figure 1.6 Exemple de diagramme de classe
Le diagramme de squence va nous permettre de dcrire les scnarios des cas

dutilisation du diagramme des cas dutilisation. titre dexemple nous montrons
(fig. 1.7) le scnario correspondant la consultation du catalogue.
sd Consulter formation
: Catalogue : Formation
: Internaute
consulterCatalogue( )
loop Consultation thme
consulterFormation( )
change de messages
entre objets
Figure 1.7 Exemple de diagramme de classe
Cette premire illustration de trois diagrammes donne dj un clairage sur les

concepts importants que sont la classe, le cas dutilisation et lobjet.
1.2.5 Schma densemble des treize diagrammes dUML 2

Afin de donner quelques points de repres sur le positionnement et les liens entre
tous les diagrammes dUML, nous donnons ici notre propre vision en proposant un
regroupement des diagrammes en quatre ensembles suivant leur finalit :
description du systme : huit diagrammes ;
architecture technique : deux diagrammes ;
vues globales ou spcialises : deux diagrammes ;
partition dlments de la modlisation : un diagramme.
Le schma propos reprend les treize diagrammes en les rpartissant sur les quatre
ensembles dfinis (fig. 1.8).
Nous avons adopt, dans cet ouvrage, les abrviations suivantes pour les treize diagrammes :
DAC : Diagramme dactivit
DCL : Diagramme de classe
DOB : Diagramme dobjet
DCP : Diagramme de composant
DCU : Diagramme des cas dutilisation
DCO : Diagramme de communication
DET : Diagramme dtat-transition
DGI : Diagramme global dinteraction
DPA : Diagramme de paquetage
DPL : Diagramme de dploiement
DSC : Diagramme de structure composite
DSE : Diagramme de squence
DTP : Diagramme de temps
Description du systme Vues

globales
DCU DSE ou DCO ou
(interactions acteur/systme) (interactions acteur/objets) spcialises
DOB
DGI
+ (objets)
(vue macro
DCL de DAC et DSE)
DAC (classes DET
(processus, et associations) + (tats dobjet)
flots de contrle
et de donnes)
DTP
(tats dobjet et temps)
Architecture technique DSC

(collaboration
DCP DPL dlments
(composants techniques) (dploiement composites)
des composants techniques)
Description des lments de la modlisation

DPA
(structuration des lments de la modlisation en paquetage)
Figure 1.8 Schma densemble des treize diagrammes dUML 2

Les noms en italiques reprsentent les diagrammes de comportement
2
Les diagrammes structurels
(ou statiques)
2.1 DIAGRAMME DE CLASSE (DCL) ET DIAGRAMME

DOBJET (DOB)
Le diagramme de classe constitue lun des pivots essentiels de la modlisation avec
UML. En effet, ce diagramme permet de donner la reprsentation statique du
systme dvelopper. Cette reprsentation est centre sur les concepts de classe et
dassociation. Chaque classe se dcrit par les donnes et les traitements dont elle est
responsable pour elle-mme et vis--vis des autres classes. Les traitements sont mat-
rialiss par des oprations. Le dtail des traitements nest pas reprsent directement
dans le diagramme de classe ; seul lalgorithme gnral et le pseudo-code correspon-
dant peuvent tre associs la modlisation.
La description du diagramme de classe est fonde sur :
le concept dobjet,
le concept de classe comprenant les attributs et les oprations,
les diffrents types dassociation entre classes.
2.1.1 Objet
Nous allons donner une premire dfinition du concept dobjet avant de traiter le
concept de classe. La description dun objet sera complte simultanment la
prsentation du concept de classe.
Un objet est un concept, une abstraction ou une chose qui a un sens dans le con-
texte du systme modliser. Chaque objet a une identit et peut tre distingu des
autres sans considrer a priori les valeurs de ses proprits.
18 Chapitre 2. Les diagrammes structurels (ou statiques)
Exemple
La figure 2.1 montre des exemples dobjets physiques (une chaise, une voiture, une
personne, un vlo) et dobjets de gestion (la Commande n 12, le Client Durand).
Co mmande Client
n 12 Durand
Figure 2.1 Exemples dobjets physiques et dobjets de gestion
Autres caractristiques
Un objet est caractris par les valeurs de ses proprits qui lui confrent des tats
significatifs suivant les instants considrs. Le formalisme de reprsentation dun
objet est donn aprs celui dune classe.
2.1.2 Classe, attribut et opration

Classe
Une classe dcrit un groupe dobjets ayant les mmes proprits (attributs), un
mme comportement (oprations), et une smantique commune (domaine de dfi-
nition).
Un objet est une instance dune classe. La classe reprsente labstraction de ses
objets. Au niveau de limplmentation, cest--dire au cours de lexcution dun pro-
gramme, lidentificateur dun objet correspond une adresse mmoire.
Formalisme gnral et exemple

Une classe se reprsente laide dun rectangle comportant plusieurs compartiments.
Les trois compartiments de base sont :
la dsignation de la classe,
la description des attributs,
la description des oprations.
Deux autres compartiments peuvent tre aussi indiqus :

la description des responsabilits de la classe,
la description des exceptions traites par la classe.
2.1 Diagramme de classe (DCL) et diagramme dobjet (DOB) 19
Il est possible de manipuler les classes en limitant le niveau de description un

nombre rduit de compartiments selon les objectifs poursuivis par le modlisateur.
Ainsi les situations suivantes sont possibles pour la manipulation dune description
restreinte de classe :
description uniquement du nom et des caractristiques gnrales de la classe,
description du nom de la classe et de la liste dattributs.
La figure 2.2 montre le formalisme gnral des compartiments dune classe et des
premiers exemples.
Nom de la classe
Voiture Client
Attributs
Marque
Oprations Puissance Description rduite
la dsignation
de la classe
Responsabilits Classe rduite
et/ou exception deux compartiments
Description complte
Figure 2.2 Formalisme gnral dune classe et exemples
Attribut
Un attribut est une proprit lmentaire dune classe. Pour chaque objet dune
classe, lattribut prend une valeur (sauf cas dattributs multivalus).
La figure 2.3 montre le formalisme et un exemple de reprsentation des attributs de
classe.
Nom de la classe Voiture
Nom et caractristique attribut 1 Num_immatriculation : texte

Nom et caractristique attribut 2

Figure 2.3 Formalisme dattributs de classe et exemple

Caractristiques
Le nom de la classe peut tre qualifi par un strotype . La description complte
des attributs dune classe comporte un certain nombre de caractristiques qui
doivent respecter le formalisme suivant :
Visibilit/Nom attribut : type [= valeur initiale {proprits}]
Visibilit : se reporter aux explications donnes plus loin sur ce point.
Nom dattribut : nom unique dans sa classe.
Type : type primitif (entier, chane de caractres) dpendant des types
disponibles dans le langage dimplmentation ou type classe matrialisant
un lien avec une autre classe.
Valeur initiale : valeur facultative donne linitialisation dun objet de la
classe.
{proprits} : valeurs marques facultatives (ex. : interdit pour mise jour
interdite).
Un attribut peut avoir des valeurs multiples. Dans ce cas, cette caractristique est
indique aprs le nom de lattribut (ex. : prnom [3] pour une personne qui peut
avoir trois prnoms).
Un attribut dont la valeur peut tre calcule partir dautres attributs de la classe
est un attribut driv qui se note /nom de lattribut driv . Un exemple dattribut
driv est donn la figure 2.5.
Opration
Une opration est une fonction applicable aux objets dune classe. Une opration
permet de dcrire le comportement dun objet. Une mthode est limplmentation
dune opration.
Chaque opration est dsigne soit seulement par son nom soit par son nom, sa liste
de paramtres et son type de rsultat. La signature dune mthode correspond au
nom de la mthode et la liste des paramtres en entre. La figure 2.4 montre le
formalisme et un exemple de reprsentation doprations de classe.
Nom de la classe Voiture
Nom et caractristique attributs

marque : texte

rouler (vitesse)
Nom et caractristique opration 1
Nom et caractristique opration 2

Figure 2.4 Formalisme et exemple doprations de classe

Caractristiques
La description complte des oprations dune classe comporte un certain nombre de
caractristiques qui doivent respecter le formalisme suivant :
Visibilit Nom dopration (paramtres) [:[type rsultat] {proprits}]
Visibilit : se reporter aux explications donnes plus loin sur ce point.
Nom dopration : utiliser un verbe reprsentant laction raliser.
Paramtres : liste de paramtres (chaque paramtre peut tre dcrit, en plus
de son nom, par son type et sa valeur par dfaut). Labsence de paramtre
est indique par ( ).
Type rsultat : type de (s) valeur(s) retourn(s) dpendant des types dispo-
nibles dans le langage dimplmentation. Par dfaut, une opration ne
retourne pas de valeur, ceci est indiqu par exemple par le mot rserv
void dans le langage C++ ou Java.
{proprits} : valeurs facultatives applicables (ex. : {query} pour un compor-
tement sans influence sur ltat du systme).
Exemples de classes et reprsentation dobjets
La figure 2.5 prsente lexemple dune classe Voiture . La figure 2.6 donne le
formalisme dun objet.
Voiture
marque : texte
puissance : entier
cylindre : entier
anne : entier
/anciennet : entier
dmarrer ( )
rouler ( )
freiner ( )
arrter ( )
Figure 2.5 Exemple de reprsentation dune classe
Nom de lobjet (1)
valeur attribut 1
valeur attribut 2
valeur attribut N
Figure 2.6 Formalisme de reprsentation dun objet

(1) Le nom dun objet peut tre dsign sous trois formes : nom de lobjet, dsignation directe et
explicite dun objet ; nom de lobjet : nom de la classe, dsignation incluant le nom de la classe ;
: nom de la classe, dsignation anonyme dun objet dune classe donne.
Il est utile de prciser que la reprsentation des objets sera utilise dans plusieurs
autres diagrammes importants dUML. Cest le cas notamment du diagramme de
squence ou encore du diagramme dtat-transition.
La figure 2.7 prsente des exemples dobjets.
mavoiture mavoiture : Voiture : Voiture
audi audi
10 CV 10 CV
2L 2L
2001 2001
Figure 2.7 Exemples de reprsentation dobjets
Visibilit des attributs et oprations

Chaque attribut ou opration dune classe peut tre de type public, protg, priv ou
paquetage. Les symboles + (public), # (protg), - (priv) et ~ (paquetage) sont indi-
qus devant chaque attribut ou opration pour signifier le type de visibilit autoris
pour les autres classes.
Les droits associs chaque niveau de confidentialit sont :
Public (+) Attribut ou opration visible par tous.
Protg (#) Attribut ou opration visible seulement lintrieur de la classe
et pour toutes les sous-classes de la classe.
Priv (-) Attribut ou opration seulement visible lintrieur de la classe.
Paquetage (~) Attribut ou opration ou classe seulement visible lint-
rieur du paquetage o se trouve la classe.
Exemple
La figure 2.8 montre un exemple dutilisation des symboles de la visibilit des
lments dune classe.
Dans cet exemple, tous les attributs sont dclars de type priv, les oprations
dmarrer et freiner sont de type public, lopration rouler est de type
priv et lopration arrter est de type protg.
Attribut ou opration de niveau classe

Caractristiques
Un attribut ou une opration peut tre dfini non pas au niveau des instances dune
classe, mais au niveau de la classe. Il sagit soit dun attribut qui est une constante
pour toutes les instances dune classe soit dune opration dune classe abstraite (voir
2.1.6) ou soit par exemple dune opration crer qui peut tre dfinie au niveau
de la classe et applicable la classe elle-mme.
Voiture
- marque
- puissance
- cylindre
- anne
- chiffreAffaire
+ dmarrer ( )
- rouler ( )
+ freiner ( )
# arrter ( )
Figure 2.8 Exemple de reprsentation des symboles de visibilit
Cest le soulignement de lattribut ou de lopration qui caractrise cette proprit.
Dans lexemple de la figure 2.9, lattribut ristourne est de type classe et lopra-
tion crer est une opration excutable au niveau de la classe.
Voiture
- marque
- puissance
- cylindre
- anne
- chiffreAffaire
- ristourne
- crer ( )
+ dmarrer ( )
+ rouler ( )
+ freiner ( )
+ arrter ( )
Figure 2.9 Exemple dattribut ou dopration de niveau classe
2.1.3 Association, multiplicit, navigabilit et contraintes

Lien et association
Un lien est une connexion physique ou conceptuelle entre instances de classes donc
entre objets. Une association dcrit un groupe de liens ayant une mme structure et
une mme smantique. Un lien est une instance dune association. Chaque associa-
tion peut tre identifie par son nom.
Une association entre classes reprsente les liens qui existent entre les instances
de ces classes.
La figure 2.10 donne le formalisme de lassociation. Le symbole (facultatif) indique
le sens de lecture de lassociation. Dans cette figure est donn aussi un exemple de
reprsentation dune association.
Nom de classe A Nom de classe B

Nom de lassociation
Personne Voiture
Possder
Figure 2.10 Formalisme et exemple dassociation
Rle dassociation
Le rle tenu par une classe vis--vis dune association peut tre prcis sur lassocia-
tion.
Exemple
La figure 2.11 donne un exemple de rle dassociation.
Personne Entreprise
Travailler dans
nom nom entreprise

prnom employ adresse
employeur
Figure 2.11 Exemple de rles dune association
Multiplicit
La multiplicit indique un domaine de valeurs pour prciser le nombre dinstance
dune classe vis--vis dune autre classe pour une association donne. La multiplicit
peut aussi tre utilise pour dautres usages comme par exemple un attribut multi-
valu. Le domaine de valeurs est dcrit selon plusieurs formes :
Intervalle ferm Exemple : 2, 3 ..15.
Valeurs exactes Exemple : 3, 5, 8.
Valeur indtermine note * Exemple : 1..*.

Dans le cas o lon utilise seulement *, cela traduit une multiplicit 0..*.
Dans le cas de multiplicit dassociations, il faut indiquer les valeurs mini-
male et maximale dinstances dune classe vis--vis dune instance dune
autre classe.
Nous donnons, la figure 2.12, quelques exemples des principales multiplicits dfi-
nies dans UML.
* 0..1
une instance de A correspond
A B 0 ou 1 instance de B.
une instance de B correspond
0 nombre non dtermin
dinstances de A.
2..10 1..* une instance de A correspond

1 un nombre non dtermin
A B
dinstances de B.
2 10 instances de A.
1, 3 2..4 une instance de A correspond

A B 2 4 instances de B.
1 ou 3 instances de A.
Figure 2.12 Exemple de multiplicits
Navigabilit
La navigabilit indique si lassociation fonctionne de manire unidirectionnelle ou
bidirectionnelle, elle est matrialise par une ou deux extrmits flches. La non-
navigabilit se reprsente par un X
Les situations possibles de navigabilit sont reprsentes la figure 2.13.
A B Navigabilit unidirectionnelle de A vers B.

Pas de navigabilit de B vers A
Navigabilit unidirectionnelle de B vers A.

A B Navigabilit de A vers B
Navigabilit bidirectionnelle entre A et B.

A B
Figure 2.13 Reprsentation de la navigabilit dassociation

Par dfaut, on admet quune navigabilit non dfinie correspond une navigabi-
lit implicite.
Dans lexemple donn la figure 2.14, une personne sont associes ses copies
dexamen mais linverse nest pas possible (retrouver directement lauteur de la copie
dexamen, notamment avant la correction de la copie).
Personne Copie dexamen

1 produit 1..5
nom numro copie
prnom
Figure 2.14 Exemple de navigabilit dune association
Contraintes
Dautres proprits particulires (contraintes) sont proposes dans UML pour
prciser la smantique dune association.
Ordre de tri
Pour une association de multiplicit suprieure 1, les liens peuvent tre :
non ordonns (valeur par dfaut),
ordonns ou tris lorsque lon est au niveau de limplmentation (tri sur une
valeur interne).
Un exemple est donn la figure 2.15. Dans cet exemple, pour une entreprise
donne, les personnes seront enregistres suivant un ordre qui correspondra un des
attributs de Personne.
Personne Entreprise
1..* Travailler dans 1, 2
nom nom entreprise
prnom adresse
{ordonn}
Figure 2.15 Exemple de contrainte dordre dune association
Proprits de mise jour de liens

Il est possible dindiquer des contraintes particulires relatives aux conditions de
mise jour des liens.
{interdit} : interdit lajout, la suppression ou la mise jour des liens.
{ajout seul} : nautorise que lajout de liens.
Association de dimension suprieure 2 et classe-association

Une association de dimension suprieure 2 se reprsente en utilisant un losange
permettant de relier toutes les classes concernes.
Une classe-association permet de dcrire soit des attributs soit des oprations
propres lassociation. Cette classe-association est elle-mme relie par un trait en
pointill au losange de connexion. Une classe-association peut tre relie dautres
classes dun diagramme de classes.
Exemple
Un exemple dune association de dimension 3 comprenant une classe-association
Affectation est donn la figure 2.16. La classe-association Affectation permet
de dcrire les attributs propres lassociation de dimension 3 reprsente.
Projet
code projet
affecter ( )
Entreprise
*
nom entreprise
Personne Mobiliser adresse
* *
nom
prnom
Travailler Employer
Affectation
date dbut
date fin
Classe Association
Figure 2.16 Exemple dune association de dimension 3

et dune classe-association
2.1.4 Agrgation et composition entre classes

Agrgation
Lagrgation est une association qui permet de reprsenter un lien de type
ensemble comprenant des lments . Il sagit dune relation entre une classe
reprsentant le niveau ensemble et 1 n classes de niveau lments . Lagrga-
tion reprsente un lien structurel entre une classe et une ou plusieurs autres classes.
La figure 2.17 donne le formalisme gnral de lagrgation.
Classe 1
Classe 2
Figure 2.17 Formalisme de lagrgation
La figure 2.18 montre un exemple de relation dagrgation. Dans cet exemple, nous
avons modlis le fait quun ordinateur comprend une UC, un clavier et un cran.
Ordinateur
puissance
marque
1 1 1
U.C. Clavier cran
Figure 2.18 Exemple dagrgation
Composition
La composition est une relation dagrgation dans laquelle il existe une contrainte
de dure de vie entre la classe composant et la ou les classes compos . Autre-
ment dit la suppression de la classe compos implique la suppression de la ou des
classes composant .
La figure 2.19 donne le formalisme gnral de la composition. La figure 2.20 montre
un exemple de relation de composition. Une seconde forme de prsentation peut
tre aussi utilise, elle est illustre la figure 2.21.
Classe 1
Classe compos
Classe 2
Classe composant
Figure 2.19 Formalisme de la composition
Commande
1 1..*
En-tte Lignes commandes
Figure 2.20 Exemple dune relation de composition
Commande
En-tte 1
Lignes commandes 1..*
Figure 2.21 Exemple de la seconde forme de reprsentation

de la relation de composition
2.1.5 Association qualifie, dpendance et classe dinterface

Qualification
La qualification dune relation entre deux classes permet de prciser la smantique
de lassociation et de qualifier de manire restrictive les liens entre les instances.
Seules les instances possdant lattribut indiqu dans la qualification sont con-
cernes par lassociation. Cet attribut ne fait pas partie de lassociation.
Soit la relation entre les rpertoires et les fichiers appartenant ces rpertoires. un
rpertoire est associ 0 n fichiers. Si lon veut restreindre cette association pour ne
considrer quun fichier associ son rpertoire, la relation qualifie est alors utilise
pour cela. La figure 2.22 montre la reprsentation de ces deux situations.
Rpertoire Fichier
1 contenir *
1 1
Rpertoire nom de fichier Fichier
Figure 2.22 Formalisme et exemple dassociation qualifie
Dpendance
La dpendance entre deux classes permet de reprsenter lexistence dun lien sman-
tique. Une classe B est en dpendance de la classe A si des lments de la classe A
sont ncessaires pour construire la classe B.
La relation de dpendance se reprsente par une flche en pointill (fig. 2.23) entre
deux classes.
Classe A Classe B
Figure 2.23 Formalisme de reprsentation dun lien de dpendance

Interface
Une classe dinterface permet de dcrire la vue externe dune classe. La classe
dinterface, identifie par un nom, comporte la liste des oprations accessibles par les
autres classes. Le compartiment des attributs ne fait pas partie de la description dune
interface.
Linterface peut tre aussi matrialise plus globalement par un petit cercle asso-
ci la classe source.
La classe utilisatrice de linterface est relie au symbole de linterface par une fl-
che en pointill. La classe dinterface est une spcification et non une classe relle.
Une classe dinterface peut sassimiler une classe abstraite.
La figure 2.24 donne le formalisme, sur un exemple, des deux types de reprsentation
dune interface.
Fentre Mot de passe
code numro
1* Donner accs 1
dlacer ( ) contrler ( )
ouvrir ( )
fermer ( )
utilise
ralise interface
Autorisation Indique que la classe
Indique que la classe Mot de passe utilise
Fentre ralise linterface Autorisation
linterface Autorisation
ouvrir ( )
Indique que la classe

Mot de passe utilise
une interface de la classe Fentre
Autorisation appele Autorisation
Fentre Mot de passe
code numro
1* Donner accs 1
dlacer ( ) contrler ( )
ouvrir ( )
fermer ( )
Figure 2.24 Exemple de description dune classe dinterface

2.1.6 Gnralisation et spcialisation

La gnralisation/spcialisation et lhritage simple
La gnralisation est la relation entre une classe et deux autres classes ou plus parta-
geant un sous-ensemble commun dattributs et/ou doprations.
La classe qui est affine sappelle super-classe, les classes affines sappellent
sous-classes. Lopration qui consiste crer une super-classe partir de classes
sappelle la gnralisation. Inversement la spcialisation consiste crer des sous-
classes partir dune classe.
La figure 2.25 montre le formalisme de la gnralisation-spcialisation sous forme
dexemple gnral. Dans cet exemple :
la sous-classe A1 hrite de A, cest une spcialisation de A ;
la sous-classe A2 hrite de A, cest une spcialisation de A.
Classe A
Spcialisation Gnralisation
(hritage)
Sous-classe Sous-classe
A1 A2
Figure 2.25 Formalisme de la relation de gnralisation
Lhritage permet une sous-classe de disposer des attributs et oprations de la

classe dont elle dpend. Un discriminant peut tre utilis pour exploiter le critre de
spcialisation entre une classe et ses sous-classes. Le discriminant est simplement
indiqu sur le schma, puisque les valeurs prises par ce discriminant correspondent
chaque sous-classe.
La figure 2.26 montre un exemple de relation de spcialisation. Dans cet exem-

ple, les attributs nom, prnom et date de naissance et lopration calculer ge de
Employ sont hrits par les trois sous-classes : Employ horaire, Employ salari,
Vacataire.
Classe abstraite
Une classe abstraite est une classe qui na pas dinstance directe mais dont les classes
descendantes ont des instances. Dans une relation dhritage, la super-classe est par
dfinition une classe abstraite. Cest le cas de la classe Employ dans lexemple
prsent la figure 2.26.
Employ
nom
prnom
date naissance
calculer ge ( )
Employ horaire Employ salari Vacataire
taux horaire taux taux journalier

taux horaire hebdomadaire
supplmentaire
calculer paie ( ) calculer paie ( ) calculer paie ( )
Figure 2.26 Exemple de relation de spcialisation
Lhritage avec recouvrement

Par dfaut, les sous-classes ont des instances disjointes les unes par rapport aux
autres. Dans certains cas, il existe un recouvrement dinstances entre les sous-classes.
Dune manire gnrale, quatre situations peuvent se rencontrer et se reprsentent
sous forme de contraintes :
{chevauchement} : deux sous-classes peuvent avoir, parmi leurs instances, des
instances identiques ;
{disjoint} : les instances dune sous-classe ne peuvent tre incluses dans une
autre sous-classe de la mme classe ;
{complte} : la gnralisation ne peut pas tre tendue ;

{incomplte} : la gnralisation peut tre tendue.
Dans certains cas, il est possible de ne pas citer toutes les sous-classes mais dindi-
quer seulementdes points de suspension ().
La figure 2.27 montre un exemple dhritage avec recouvrement dinstances entre
les classes tudiant et Employ. En effet, une mme personne peut tre la fois
tudiante dans une universit et employe dans une entreprise.
Personne
tudiant Employ
{chevauchement}
1..*
tre inscrit 1..*
Travailler
1
1
Universit
Entreprise
Figure 2.27 Exemple dhritage avec recouvrement dinstances
Extension et restriction de classe

Lajout de proprits dans une sous-classe correspond une extension de classe. Le
masquage de proprits dans une sous-classe correspond une restriction de classe.
La figure 2.28 montre un exemple dhritage avec restriction et extension.
Lhritage multiple
Dans certains cas, il est ncessaire de faire hriter une mme classe de deux classes
parentes distinctes. Ce cas correspond un hritage multiple.
Exemple
La figure 2.29 montre un exemple classique dhritage multiple o la classe Vhicule
amphibie hrite des classes Vhicule terrestre et Vhicule marin .
Classe A
nom
prnom
ge
Classe A1 Classe A2
nom nom
extension
prnom ge
ge restriction
sexe
crer ( )
crer ( )
Figure 2.28 Exemple dhritage avec extension et restriction de proprits
Vhicule
Vhicule Vhicule
terrestre marin
Vhicule Bateau
Auto amphibie
Figure 2.29 Exemple de relation dhritage multiple

2.1.7 Strotype de classe

UML propose un certain nombre de strotypes qui permettent de qualifier les
profils dutilisation.
Parmi ces strotypes, nous prsentons ci-aprs quatre dentre eux :
Classe dimplmentation Ce strotype est utilis pour dcrire des clas-
ses de niveau physique.
Type Ce strotype permet de spcifier des oprations applicables un
domaine dobjets. Exemple : Type Integer dun langage de programmation.
Utilitaire Ce strotype qualifie toutes les fonctions utilitaires de base
utilises par les objets.
MtaClasse Ce strotype permet de regrouper des classes dans une
famille de classe.
2.1.8 Exercices
Nous proposons au lecteur une srie de quatre exercices sur le diagramme de classe
ainsi quun exercice de synthse (Locagite) pour lequel nous fournirons au fur et
mesure du parcours sur UML les principaux diagrammes.
Exercice 1
nonc
Il est demand de reprsenter le diagramme de classe dune gestion technique de
documents. Chaque document est compos dun ou plusieurs feuillets. Un feuillet
comporte du texte et des objets gomtriques qui constituent deux types dobjets
graphiques supportant des oprations de type : slectionner, copier, couper, coller et
dplacer.
Nous considrons les quatre objets gomtriques suivants : cercle, ellipse, carr,
rectangle. Il est demand dutiliser les proprits de la gnralisation et la spcialisa-
tion afin de reprsenter au mieux ces objets gomtriques.
Corrig
La figure 2.30 propose au lecteur un corrig type. Dautres variantes peuvent tre
envisages notamment dans les choix de gnralisation et spcialisation.
Exercice 2
nonc
Une entreprise nationale de vente dappareil lectromnager souhaite raliser une
premire exprience danalyse objet avec la mthode UML sur un petit sous-
ensemble de son SI. Ce sous-ensemble concerne le suivi des personnels des agences
locales implantes dans les rgions. Chaque rgion est pilote par une direction
rgionale qui a en charge un certain nombre dagences locales. Une direction rgio-
nale est caractrise par un code et un libell.
Objet graphique
Document Feuillet
nom
nom nom
copier ( )
ouvrir ( ) 1..* ouvrir ( ) coller ( )
1..*
fermer ( ) fermer ( ) couper ( )
dplacer ( )
Objet gomtrique Texte

nom
Rond Ligne
centre x
rayon y
dessiner ( ) dessiner ( )
Quadrilatre
Cercle Ellipse
Carr Rectangle
Figure 2.30 Diagramme de classe de lexercice 1
Chaque agence est caractrise par un code, un intitul, une date de cration et
une date de fermeture.
une agence sont rattaches une plusieurs personnes. Chaque personne est
caractrise par les donnes : numro, qualit (M., Mme, Mlle), nom, prnom, date
de naissance, date prvisionnelle darrive, date darrive et date de dpart.
Il est demand dlaborer le diagramme de classe de ce premier sous-ensemble du
SI de cette entreprise.
Corrig
Les trois classes constituant ce systme sont videntes puisque dj bien identifies
dans lnonc : Direction rgionale, Agence et Personnel.
Lassociation entre Direction rgionale et Agence est une agrgation qui matria-
lise une relation structurante entre ces classes. La relation entre Agence et Person-
nel est une association de un plusieurs.
Les oprations mentionnes dans chaque classe correspondent aux oprations
lmentaires ncessaires la gestion du personnel des agences.
Le corrig type est donn la figure 2.31. Nous donnons aussi, figure 2.32, un
exemple de diagramme dobjet associ ce diagramme de classe.
Direction rgionale
code : nombre
libell : texte DIAGRAMME DE CLASSE
DE L'EXERCICE 2
consulter ( )
demander-crer-agence ( )
demander-supprimer-agence ( )
comprendre
Personnel
1..* code : nombre
date arrive agence : DATE
numro : nombre
Agence qualit : texte
code : nombre nom : texte
intitul : texte prnom : texte
date cration : DATE date naissance : DATE
date fermeture : DATE date prvisionnelle arrive : DATE
appartenir
date arrive agence : DATE
crer ( ) date dpart agence : DATE
1 1..*
supprimer ( ) crer ( )
modifier ( ) supprimer ( )
visualiser ( ) rechercher ( )
imprimer ( ) imprimer ( )
rattacher_personnel ( ) modifier ( )
dtacher_personnel ( ) rattacher lagence ( )
Dir-rg-Alsace
EXEMPLE
15 DE DIAGRAMME DOBJET
Alsace
comprendre
Ag-Strasbourg : Agence
: personnel
671
Strasbourg appartenir
15/01/98
Figure 2.32 Exemple de diagramme dobjet associ au diagramme de classe

de lexercice 2
Exercice 3
nonc
La socit Forma possde un service qui gre la formation interne. Sa mission
comporte plusieurs fonctions :
laborer les catalogues qui dcrivent les cours et donnent les dates prvision-
nelles des sessions.
Inscrire les personnes qui dsirent participer aux sessions et leur envoyer leur
convocation.
Dterminer les formateurs qui vont animer les sessions et leur envoyer leur
convocation (ces personnes sont choisies parmi celles qui peuvent enseigner
un cours). Certaines sessions peuvent tre animes par une personne dun
organisme extrieur.
Faire le bilan des participations relles aux formations.
Les cours sont dtermins afin de rpondre aux besoins de formation internes.
Certains cours sont organiss en filires, cest--dire quils doivent tre suivis dans un
certain ordre. Exemple : le cours ITE 16 (la dmarche ITEOR OO) ne peut tre
suivi avant ITE 03 (UML). Les cours utilisent des documents rfrencs (tab. 2.1).
Tableau 2.1 Documents rfrencs
Liste des attributs
Code cours N catalogue
Date catalogue N document
Date session N session
Dure cours Nom
tat de la session (prvue, annule, en cours, close) Organisme extrieur
Intitul du cours Prnom
Lieu session Service
Matricule Titre document
Corrig
La lecture du sujet et en particulier lanalyse des attributs indiqus conduisent
identifier rapidement les classes suivantes : Session, Cours, Catalogue, Document,
Personne et Organisme.
Une rflexion complmentaire mene sur la classe Personne permet de distinguer
en fait trois sous-classes spcialises : PersonneExterne, PersonneIntNe (non ensei-
gnante) et PersonneIntEn (enseignante).
Le diagramme de classes peut tre labor ensuite sans difficult. La figure 2.33
donne le corrig type de cet exercice.
Document
-n document
habiliter animer -titre document
Personne
-matricule +crer ( )
-nom
-prnom 0..*
Session
+crer ( ) utiliser
0..* -n session-cours
-date session 0..* 0..*
-tat
PersExt PersIntNEns PersIntEns -lieu Cours
1..* 0..*
-service -service 1 -code cours
+crer ( )
+enseigner ( ) +inscrire ( ) +annuler ( ) se drouler -intitul ncessiter
+enseigner ( ) +commencer ( ) -dure
0..*
0..* +clore ( )
1 0..* 0..* +convoquer ( ) +crer ( )
inscrire
0..*
diriger 1..*
Catalogue
Organisme
-n catalogue
1 -organisme -date
1
rattacher +crer ( ) +crer ( )
Exercice 4
nonc
Il vous est demand de grer les apports de raisin de la cooprative viticole de cham-
pagne. Le processus de traitements des apports de raisin correspond un droule-
ment en plusieurs tapes.
Dpart des camions pour le ramassage des raisins Le ramassage est orga-
nis par le responsable du transport. Tous les matins, durant la campagne de
ramassage, chaque chauffeur-livreur charge dans son camion un certain
nombre de palettes vides et passe la pese. Le responsable du transport
enregistre le dpart du camion en lui affectant un n dapport ainsi que son
poids vide (la gestion des itinraires ne fait pas partie de la prsente
tude).
Les camions ont t pralablement rpertoris par la cooprative avec leur
capacit exprime en nombre de palettes. Il est frquent quun mme
camion soit utilis pour plusieurs apports.
Retour des camions et pese des apports Larrive dun camion de palettes
de caisses de raisins correspond un apport de raisin. Les date et heure darri-
ve de cet apport sont soigneusement notes dans un registre avec le numro
dimmatriculation du camion.
Ds larrive dun apport, les palettes sont dcharges puis peses. Le poids et
le nombre de caisses par palettes sont soigneusement contrls par le respon-
sable de la pese puis enregistrs.
Constitution des lots Aprs la pese des palettes reues, le responsable de la

cooprative rpartit lapport en lots. Chaque lot correspond aux palettes
contenant les raisins de mme cpage et de mme cru. Un exemple de lot est
fourni ci-aprs (tab.2.2) : il sagit du troisime lot de lapport numro 3101 qui
regroupe les palettes du Chardonnay en provenance de Cormigny.
Le raisin de Champagne se divise en trois cpages : le Chardonnay qui est un raisin

blanc, le Pinot noir et le Pinot meunier qui sont des raisins noirs. Le cru est la prove-
nance du raisin : il correspond un nom de commune et est identifi par le numro
Insee de cette commune. Un cru possde un classement de 80 100 qui est remis en
cause chaque anne. Les classements annuels successifs dun cru doivent tre mmoriss.
Les palettes appartiennent toutes la cooprative. Elles possdent un numro qui
est peint sur le bois et qui permet de les identifier sans ambigut. Elles sont la libre
disposition des livreurs. Une mme palette peut servir plusieurs fois au cours dune
mme vendange.
Un lot concerne un livreur. Tous les livreurs sont obligatoirement connus de la
cooprative. Un bulletin dinformation professionnel leur est adress rgulirement.
Les livreurs sont des cooprateurs ou des particuliers indpendants.
Les cooprateurs exploitent une ou plusieurs parcelles. Pour chaque livreur coo-
prateur, le pourcentage de sa production quil apporte la cooprative est enregis-
tr. En aucun cas un cooprateur ne peut tre un indpendant et vice versa.
En ce qui concerne les livreurs indpendants, il est important de connatre le sta-
tut juridique quils ont choisi. Celui-ci est identifi par le code du statut et se carac-
trise par un libell (entreprise individuelle, socit responsabilit limite, socit
cooprative dexploitation agricole, etc.).
Tableau 2.2 Exemple de lot
COOPRATIVE NOUVELLE DE CHAMPAGNE

Apport n: 3101
Lot n: 3
Cpage : Chardonnay
Cru : Cormigny
Code Insee : 51231
Nom du livreur : Dupond Laurent
Numro Nombre Poids net

de palette de caisses en kg
428 8 459
102 14 642
14 10 670
123 12 578
Corrig
La lecture du sujet et en particulier lanalyse des attributs indiqus conduisent
identifier rapidement les classes suivantes : Apport, Camion, Lot, Palette, Cpage,
Commune, Livreur et Parcelle.
Le diagramme de classes peut tre labor ensuite sans difficult. La figure 2.34
donne le corrig type de cet exercice.
Apport
Camion -napport
1 * -poidsVide
-ncamion
-nitinraire
-nbMaxiPalette
-dateArrive Pese
* -dateDpart
-nbCamions
* -poids
1
peser
concerner rpartir
*
1 Lot
Livreur -nLot
*
Palette
0..* -nPalette
0..*
appartenir
correspondre
1
Cooprative Indpendant 1
-%Production Cepage Commune
* -codeCepage -nInsee
1
-nomCommune
choisir
exploiter
Classement 0..*
1
*
Statut -nClassement classer
Parcelle
-nParcelle -codeStatut 0..*
-libelleStatut
Anne

Exercice de synthse : Locagite

nonc
Locagite est une association qui permet divers propritaires ruraux de mettre
en location, la semaine, des gtes meubls. Elle publie annuellement un catalogue
contenant les gtes proposs par les propritaires. Les gtes doivent rpondre un
certain nombre de critres qualit, correspondant un nombre dtoiles, qui sont
vrifies lors de ladhsion du gte et une fois tous les trois ans lors dune visite de
contrle. Le propritaire reoit tous les ans un catalogue des gtes, et peut modifier
les informations qui le concernent (prix par saison, photo du gte, nombre de
personnes, de chambres, terrain...).
Locagite regroupe 450 gtes en France, pour une moyenne de 12 semaines de
rservation par gte et par an.
Locagite propose aux propritaires qui le souhaitent, un service central de
rservation. Tous les ans, les propritaires qui veulent utiliser ce service signent un
contrat avec Locagite , qui spcifie les priodes ouvertes la location et la rmu-
nration de la centrale de rservation en pourcentage de chaque location, ce dernier
taux tant valable pour lanne et pour lensemble des gtes. Le propritaire, en
signant le contrat, joint un relev didentit bancaire.
Le propritaire ayant sign le contrat de la rservation centrale reoit chaque
mois un tat des rservations fermes. Il reoit aussi tous les mois un tat des sommes
encaisses par la centrale de rservation. Le virement bancaire des sommes dues,
correspondant ltat prcdent, est envoy en milieu du mois suivant.
Un client potentiel (que lon peut appeler client rservataire) tlphone la cen-
trale de rservation pour rserver un gte sur la base du catalogue. La centrale de
rservation prend en compte la demande, et lui envoie un contrat de location ainsi
quune demande dacompte si un accord a t trouv sur les dates de rservation. Le
client rservataire renvoie le contrat sign accompagn de lacompte : la rservation
devient ferme. Un mois avant le sjour, le client locataire envoie le solde du
paiement ; il reoit alors une confirmation de sjour lui donnant les coordonnes de
la personne contacter pour convenir de son arrive. Le client peut tout moment
annuler son sjour, 30 % des sommes verses ne sont pas rembourses. En cas de
non-retour du contrat sign aprs 15 jours, la pr-rservation est automatiquement
annule.
Corrig
laboration du diagramme de classe : lanalyse de lensemble des donnes disponi-
bles nous permet de mettre en vidence les classes suivantes : Propritaire, Gte,
Gtes grs, Catalogue, Activit, Priode Location, Rservation, Client et Contrat
Location. Le diagramme de classe correspondant est donn la figure 2.35.
Tableau 2.3 Principales informations portes par les documents changs
Catalogue
Anne du catalogue Capacit (nb. de chambres)

N du gte Description du gte (texte)
Nom de la commune Adresse et tl. du propritaire (pour la
Adresse du gte rservation) ou tl. du service de rservation
Animaux accepts (O, N) Tarifs semaine (HS, juin/sept/Vac Scol)
NB dtoiles Activits disponibles et distance (ex. : piscine
NB de personnes acceptes 3 km)
Contrat propritaire tat mensuel des locations
N de contrat propritaire N propritaire, nom du propritaire, adresse et

N propritaire tl. du propritaire
Nom du propritaire Par contrat, par gte et par rservation :
Adresse et tl. du propritaire N de rservation
Rfrence du gte Date darrive
Description du gte (voir ci-dessus) Date de dpart
Tarifs semaine (HS, juin/sept/Vac Scol) NB de nuits
Priodes de location Nom et adresse du locataire
NB dadultes
NB denfants
Animaux (O, N)
Montant reu,
Montant recevoir
Contrat de location
N du contrat Composition de la famille

Rfrence du gte Nom
Nom du propritaire Adresse
Ville ou village ou se situe le gte NB adultes
Dates darrive et de dpart NB denfants
Animaux domestiques (O, N)
Prix du sjour : Tlphone
Tarif de location =
prix de la semaine * nombre de semaines
Frais de dossiers (fixe)
Assurance annulation (1,5 % de la
location)
Prix total
Conditions de rservation
Acompte recevoir : date et montant

Solde recevoir : date et montant
Gte
Activit
Catalogues -nGite
-commune -codeActivit
-anne -adresse -libellAct
1..* -animalAccept -distance
paratre avoir
1..* -description +majActivit()
*
Propritaire -capacit +modifActivit()
+ajoutGite() 1..*
appartenir -nbEtoile +afficheActivit()
-nPropritaire -nbPersAccept
1..*
-adresse
-tel 1 +crationGite()
Gte non gr
+crationPropritaire() +modifNbtoile()
+contrlePropritaire() Gte gr
mettre en location +rechercheGite()
-ncontratProp
-tauxRnum
2.1 Diagramme de classe (DCL) et diagramme dobjet (DOB)
1..*
1 PriodeLocation +modifNcontratP()
Figure 2.35 Diagramme de classe de Locagite

Rservation +tatRservation()
-priode
Personnes -nRservation
-tarif 1
-nPersonne -dateArrive 0..*
-nom -dateDpart concerner Contrat Location
Client +recherchePriode() -nbNuit
-prnom
-nbAdulte -nContratLocation
-adresse -nLocataire rserver correspondre
-nbEnfant -mtRecu
-tel
-animaux -mtArecevoir
+crationClient() 1..* 1 0..1
+contrleClient() 1 -mtRecu +crationContrat()
-mtArecevoir +majMt()
+crationRservation() +destructionContrat()
+rechercheRservation()
+dtruireRservation()
Figure 2.35 Diagramme de classe de Locagite

45
2.2 DIAGRAMME DE COMPOSANT (DCP)
Le diagramme de composant permet de reprsenter les composants logiciels dun

systme ainsi que les liens existant entre ces composants.
Les composants logiciels peuvent tre de deux origines : soit des composants
mtiers propres une entreprise soit des composants disponibles sur le march
comme par exemple les composants EJB, CORBA, .NET, WSDL.
2.2.1 Composant
Chaque composant est assimil un lment excutable du systme. Il est caract-
ris par :
un nom ;
une spcification externe sous forme soit dune ou plusieurs interfaces requi-
ses1, soit dune ou plusieurs interfaces fournies2 ;
un port de connexion.
Le port dun composant reprsente le point de connexion entre le composant et

une interface. Lidentification dun port permet dassurer une certaine indpendance
entre le composant et son environnement extrieur.
Formalisme gnral
Un composant est reprsent (fig. 2.36) par un classeur avec le mot-cl composant
ou bien par un classeur comportant une icne reprsentant un module.
Figure 2.36 Formalisme gnral dun composant
2.2.2 Les deux types de reprsentation et exemples

Deux types de reprsentation sont disponibles pour modliser les composants : une
reprsentation bote noire et une reprsentation bote blanche . Pour chaque
reprsentation, plusieurs modlisations des composants sont proposes.
1. Une interface requise est une interface ncessaire au bon fonctionnement du composant.
2. Une interface fournie est une interface propose par le composant aux autres composants.
2.2 Diagramme de composant (DCP) 47
Reprsentation bote noire

Cest une vue externe du composant qui prsente ses interfaces fournies et requises
sans entrer dans le dtail de limplmentation du composant. Une bote noire peut
se reprsenter de diffrentes manires.
Connecteur dassemblage
Une interface fournie se reprsente laide dun trait et dun petit cercle et une
interface requise laide dun trait et dun demi-cercle. Ce sont les connecteurs
dassemblage.
Un exemple de modlisation avec les connecteurs dassemblage est donn la
figure 2.37, le composant Commande possde deux interfaces fournies et deux inter-
faces requises.
Figure 2.37 Reprsentation dun connecteur dassemblage
Connecteur dinterfaces
Une autre reprsentation peut tre aussi utilise en ayant recours aux dpendances
dinterfaces utilise et ralise :
pour une interface fournie, cest une relation de ralisation partant du compo-
sant et allant vers linterface ;
pour une interface requise, cest une dpendance avec le mot-cl utilise
partant du composant et allant vers linterface.
Un exemple de modlisation avec connecteurs dinterfaces est donn la figure 2.38.

Le composant Commande possde une interface fournie GestionCommande et une
interface requise Produit .
Figure 2.38 Reprsentation dun composant avec connecteur dinterfaces

Compartiment
Une dernire manire de modliser un composant avec une reprsentation bote
noire est de dcrire sous forme textuelle les interfaces fournies et requises lint-
rieur dun second compartiment.
Un exemple de modlisation avec les compartiments est donn la figure 2.39.
composant
Commande
interfaces fournies
GestionCommande
SuiviCommande
interfaces requises
Produit
Personne
Figure 2.39 Reprsentation dun composant avec compartiments
Reprsentation bote blanche

Cest une vue interne du composant qui dcrit son implmentation laide de clas-
sificateurs (classes, autres composants) qui le composent. Plusieurs modlisations
sont possibles pour la reprsentation bote blanche.
Compartiment
Une manire de modliser un composant avec une reprsentation bote blanche est
de dcrire sous forme textuelle les interfaces fournies et requises lintrieur dun
compartiment, les classificateurs (classes, autres composants) dans un autre compar-
timent, les artefacts (lment logiciel : jar, war, ear, dll) qui reprsentent physique-
ment le composant dans un dernier compartiment.
Un exemple de modlisation avec les compartiments est donn la figure 2.40.
composant
Commande
interfaces fournies
GestionCommande
SuiviCommande
interfaces requises
Produit
Personne
ralisations
DetailCommande
LigneCommande
artifacts
Commande.jar
Figure 2.40 Reprsentation bote blanche avec compartiments

2.2 Diagramme de composant (DCP) 49
Dpendance
Une autre reprsentation interne du composant peut tre aussi utilise en ayant
recours aux dpendances. Ainsi, les classificateurs qui composent le composant sont
relis celui-ci par une relation de dpendance.
Les relations entre les classificateurs (association, composition, agrgation) sont
aussi modlises. Nanmoins, si elles sont trop complexes, elles peuvent tre repr-
sentes sur un diagramme de classe reli au composant par une note.
Un exemple de modlisation bote blanche avec les dpendances est donn la
figure 2.41.
Figure 2.41 Reprsentation bote blanche avec dpendances
Ports et connecteurs
Le port est reprsent par un petit carr sur le composant. Les connecteurs permettent
de relier les ports aux classificateurs. Ils sont reprsents par une association navigable
et indiquent que toute information arrive au port est transmise au classificateur.
Un exemple de reprsentation avec port et connecteur du composant Com-
mande est donn la figure 2.42.
Figure 2.42 Reprsentation bote blanche avec connecteurs

Dans lexemple de la figure 2.42, le composant Commande est constitu de deux

classes (classificateur) relies par une agrgation : DetailCommande et LigneCom-
mande.
Linterface fournie GestionCommande est accessible de lextrieur via un port et
permet daccder via les connecteurs aux oprations des deux classes DetailCom-
mande et LigneCommande (ajouterLigneCommande, calculTotal-Commande,
calculPrixLigne).
Linterface requise Personne est ncessaire pour laffichage du dtail de la com-
mande et est accessible via un port du composant Commande.
Linterface requise Produit est ncessaire pour le calcul du prix de la ligne de
commande et est accessible via un port du composant Commande.
2.3 DIAGRAMME DE DPLOIEMENT (DPL)
Le diagramme de dploiement permet de reprsenter larchitecture physique suppor-

tant lexploitation du systme. Cette architecture comprend des nuds correspondant
aux supports physiques (serveurs, routeurs) ainsi que la rpartition des artefacts logi-
ciels (bibliothques, excutables) sur ces nuds. Cest un vritable rseau constitu
de nuds et de connexions entre ces nuds qui modlise cette architecture.
2.3.1 Nud
Un nud correspond une ressource matrielle de traitement sur laquelle des arte-
facts seront mis en uvre pour lexploitation du systme. Les nuds peuvent tre
interconnects pour former un rseau dlments physiques.
Un nud ou une instance de nud se reprsente par un cube ou paralllpipde
(fig. 2.43).
serveur serveur J2EE

application
Figure 2.43 Reprsentation de nuds

2.3 Diagramme de dploiement (DPL) 51
Complments sur la description dun nud

Il est possible de reprsenter des nuds spcialiss. UML propose en standard les
deux types de nuds suivants :
Unit de traitement Ce nud est une unit physique disposant de capacit
de traitement sur laquelle des artefacts peuvent tre dploys.
Une unit de traitement est un nud spcialis caractris par le mot-cl
device .
Environnement dexcution Ce nud reprsente un environnement
dexcution particulier sur lequel certains artefacts peuvent tre excuts.
Un environnement dexcution est un nud spcialis caractris par le mot-
cl executionEnvironment .
2.3.2 Artefact
Un artefact est la spcification dun lment physique qui est utilis ou produit par
le processus de dveloppement du logiciel ou par le dploiement du systme. Cest
donc un lment concret comme par exemple : un fichier, un excutable ou une
table dune base de donnes.
Un artefact peut tre reli dautres artefacts par notamment des liens de dpendance.
Un artefact se reprsente par un rectangle (fig. 2.44) caractris par le mot-cl
artifact et/ou une icne particulire dans le coin droit du rectangle.
Figure 2.44 Reprsentation dun artefact
Deux complments de description sont proposs par UML pour la reprsentation

des artefacts.
2.3.3 Spcification de dploiement

Une spcification de dploiement peut tre associe chaque artefact. Elle permet
de prciser les conditions de dploiement de lartefact sur le nud sur lequel il va
tre implant.
Une spcification de dploiement se reprsente par un rectangle avec le mot-cl
deployment spec . Un exemple dun artefact avec une spcification de dploie-
ment est donn la figure 2.45.
deployement spec
SpecCommande
Excution : execcmd
Figure 2.45 Exemple dun artefact avec spcification de dploiement
2.3.4 Liens entre un artefact et les autres lments du diagramme

Il existe deux manires de reprsenter le lien entre un artefact et son nud
dappartenance :
Reprsentation inclusive Dans cette reprsentation, un artefact est repr-
sent lintrieur du nud auquel il se situe physiquement. Un exemple est
donn la figure 2.46.
CommandeServeur1
<<artifact>> <<artifact>>
PriseCom.jar facture.jar
Figure 2.46 Exemple de reprsentation inclusive dartefact
Reprsentation avec un lien de dpendance typ deploy Dans ce cas

lartefact est reprsent lextrieur du nud auquel il appartient avec un lien
de dpendance entre lartefact et le nud typ avec le mot-cl deploy . Un
exemple est donn la figure 2.47.
CommandeServeur1
<<deploy>> <<deploy>>
<<artifact>> <<artifact>>
PriseCom.jar facture.jar
Figure 2.47 Exemple de reprsentation dartefact avec lien de dpendance

2.3 Diagramme de dploiement (DPL) 53
Un artefact peut reprsenter un ou plusieurs lments dun modle. Le qualifica-

tif manifest permet dindiquer ce type de dpendance.
2.3.5 Reprsentation et exemples

Le diagramme de dploiement reprsente les nuds de larchitecture physique ainsi
que laffectation des artefacts sur les nuds conformment aux rgles de dploie-
ment dfinies. Un premier exemple est donn la figure 2.48.
CommandeServeur1
<<artifact>>
facture.jar
<<artifact>>
PriseCom.jar
"deployment spec" "deployment spec"

PriseComdescr.xml facturedesc.xml
Figure 2.48 Exemple de reprsentation dun diagramme de dploiement
Un second exemple relatif une implmentation dune architecture J2EE avec

quatre nuds est donn la figure 2.49.
Dans lexemple de la figure 2.49, plusieurs composants sont dploys.
Un serveur web o se trouvent les lments statiques du site dans une
archive : images, feuilles de style, pages html (static.zip).
Un serveur dapplication front sur le lequel est dploye larchive
front.ear compose de lapplication web front.war et dautres compo-
sants ncessaires au fonctionnement de cette archive web comme client-
ejb.jar (classes permettant lappel aux EJB) et commun.jar (classes
communes aux deux serveurs dapplication).
Un serveur dapplication mtier sur lequel sont dploys les composants :
ejb.jar . Ils sont packags dans larchive metier.ear . Deux autres archi-
ves sont ncessaires au fonctionnement des EJB : dao.jar (classes qui
permettent laccs la base de donnes) et commun.jar (classes commu-
nes aux deux serveurs dapplication).
Un serveur BDD (base de donnes) sur lequel sont stockes des procdures
stockes PL/SQL : scripts.sql .
<<device>>
Serveur web
<<artifact>>
static.zip
<<device>>
Serveur application front
<<artifact>>
front.ear
<<artifact>> <<artifact>> <<artifact>>

front.war client-ejb.jar commun.jar
<<device>>
Serveur application mtier
<<artifact>>
metier.ear
<<artifact>> <<artifact>> <<artifact>>

ejb.jar commun.jar dao.jar
<<device>>
Serveur BDD
<<artifact>>
scripts.sql
Figure 2.49 Exemple de diagramme de dploiement comportant quatre nuds
2.4 DIAGRAMME DE PAQUETAGE (DPA)
2.4.1 Paquetage
Un paquetage regroupe des lments de la modlisation appels aussi membres,
portant sur un sous-ensemble du systme. Le dcoupage en paquetage doit traduire
un dcoupage logique du systme construire qui corresponde des espaces de
nommage homognes.
2.4 Diagramme de paquetage (DPA) 55
Les lments dun paquetage peuvent avoir une visibilit dclare soit de type
public (+) soit priv (-).
Un paquetage peut importer des lments dun autre paquetage. Un paquetage
peut tre fusionn avec un autre paquetage.
La figure 2.50 montre le formalisme gnral dun paquetage et les trois manires de
prsenter un paquetage.
Reprsentation globale Le nom du paquetage se trouve lintrieur du
grand rectangle.
Reprsentation dtaille Les membres du paquetage sont reprsents et le
nom du paquetage densemble sinscrit dans le petit rectangle.
Reprsentation clate Les membres du paquetage sont relis par un lien
connect au paquetage par le symbole .
Nom du
paquetage
Membre A Membre B
Nom du paquetage
Nom du paquetage
+
Membre A Membre B
Figure 2.50 Formalisme de reprsentation de paquetages
La figure 2.51 donne un exemple de reprsentation clate.
Gestion commerciale
+
Commande Facture
Figure 2.51 Exemple de reprsentation clate dun paquetage

2.4.2 Dpendance entre paquetages

La dpendance entre paquetages peut tre qualifie par un niveau de visibilit qui
est soit public soit priv. Par dfaut le type de visibilit est public.
chaque type de visibilit est associ un lien de dpendance. Les deux types de
dpendances entre paquetages sont :
import Ce type de dpendance permet, pour un paquetage donn,
dimporter lespace de nommage dun autre paquetage. Ainsi tous les membres
du paquetage donn ont accs tous les noms des membres du paquetage
import sans avoir utiliser explicitement le nom du paquetage concern. Ce
type de dpendance correspond un lien ayant une visibilit public .
access Ce type de dpendance permet, pour un paquetage donn,
davoir accs lespace de nommage dun paquetage cible. Lespace de
nommage nest donc pas import et ne peut tre transmis dautres paqueta-
ges par transitivit. Ce type de dpendance correspond un lien ayant une
visibilit priv .
Un exemple de dpendance entre paquetages mettant en jeu les niveaux de visi-

bilit est donn la figure 2.52.
Dans cet exemple, les lments de Clients externes sont imports dans Domaine
client et ensuite dans Domaine tiers. Cependant, les lments de Clients internes
sont seulement accessibles par le paquetage Domaine client et donc pas partir du
paquetage Domaine tiers.
Clients internes access
import
Domaine client Domaine tiers
Clients externes import
Figure 2.52 Exemple de liens de dpendance entre paquetages

En reprenant lexemple type de lexercice de synthse Locagite, nous donnons
(fig. 2.53) une reprsentation des liens de dpendance entre paquetages.
2.4 Diagramme de paquetage (DPA) 57
Catalogue access Propritaire
import
import
import
Location
Rservation
Figure 2.53 Exemple de liens de dpendance entre paquetages de Locagite
Enfin, UML propose aussi une opration de fusion entre deux paquetages. Le lien
de dpendance comporte dans ce cas le mot-cl merge .
Ce type de lien permet de fusionner deux paquetages et dobtenir ainsi un paque-
tage contenant la fusion des deux paquetages dorigine. Pour bien clarifier cette op-
ration, il est important de qualifier par des rles les paquetages dans cette fusion.
Ainsi trois rles sont distinguer :
le paquetage fusionner (entrant dans la fusion, mais prserv aprs la fusion) ;
le paquetage recevant (paquetage dorigine avant la fusion, mais non conserv
aprs la fusion) ;
le paquetage rsultat (paquetage contenant le rsultat de la fusion et crasant
le contenu du paquetage dorigine).
Un exemple type de fusion entre deux paquetages est donn la figure 2.54.
Paquetage fusionner Paquetage fusionner Paquetage recevant
A A B
merge fusion
devenir
B
B
Paquetage dorigine
Paquetage rsultat
Figure 2.54 Exemple de liens de fusion entre paquetages

2.5 DIAGRAMME DE STRUCTURE COMPOSITE (DSC)
Le diagramme de structure composite permet de dcrire des collaborations

dinstances (de classes, de composants) constituant des fonctions particulires du
systme dvelopper.
2.5.1 Collaboration
Une collaboration reprsente un assemblage de rles dlments qui interagissent en
vue de raliser une fonction donne. Il existe deux manires de reprsenter une
collaboration :
reprsentation par une collaboration de rles,
reprsentation par une structure composite : le diagramme de structure
composite.

Reprsentation par une collaboration de rles
Dans ce cas, une collaboration est formalise par une ellipse en pointill dans
laquelle on fait figurer les rles des lments qui interagissent en vue de raliser la
fonction souhaite (fig. 2.55). Dans cet exemple, la fonction Persistance objets mtier
rsulte dune collaboration entre deux rles dlments :
mapping : classeMtier,
stockage : tableBDD.
Persistance objets mtier
mapping : classeMtier stockage : tableBDD
Figure 2.55 Exemple de reprsentation dune structure composite

laide dune collaboration de rles
2.5 Diagramme de structure composite (DSC) 59
Reprsentation par un diagramme de structure composite

Cette nouvelle reprsentation (fig. 2.56) permet de montrer plus explicitement les
lments de la collaboration :
la collaboration reprsente par une ellipse en pointill ;
les lments participant la collaboration (classe, composant) reprsents
lextrieur de la collaboration ;
les rles considrs dans chaque participation reprsents sur les liens entre les
lments participants et la collaboration.
Persistance objets mtier

ClasseMtier TableBDD
attribut1
attribut1
attribut1
attribut1
attribut2
attribut2 attribut2
attribut2

mapping stockage
Figure 2.56 Exemple de reprsentation de collaboration dinstances

par un diagramme de structure composite
Dans cet exemple, la fonction Persistance objets mtier rsulte dune collabora-
tion entre la classe ClasseMtier considre suivant le rle mapping et la classe
TableBDD considre suivant le rle stockage.
Cette reprsentation permet aussi de prciser les seuls attributs des classes parti-
cipantes qui sont considrs suivant les rles pris en compte.
3
Les diagrammes
comportementaux
Les diagrammes comportementaux sont focaliss sur la description de la partie dyna-

mique du systme modliser. Sept diagrammes sont proposs par UML 2 pour
assurer cette description :
le diagramme des cas dutilisation (DCU),
le diagramme dtat-transition (machine dtat, DET),
le diagramme dactivit (DAC),
le diagramme de squence (DSE),
le diagramme de communication (DCO),
le diagramme global dinteraction (DGI),
le diagramme de temps (DTP).
3.1 DIAGRAMME DES CAS DUTILISATION (DCU)
3.1.1 Prsentation gnrale et concepts de base

Les cas dutilisation ont t dfinis initialement par Ivar Jacobson en 1992 dans sa
mthode OOSE. Les cas dutilisation constituent un moyen de recueillir et de
dcrire les besoins des acteurs du systme. Ils peuvent tre aussi utiliss ensuite
comme moyen dorganisation du dveloppement du logiciel, notamment pour la
structuration et le droulement des tests du logiciel.
62 Chapitre 3. Les diagrammes comportementaux
Un cas dutilisation permet de dcrire linteraction entre les acteurs (utilisateurs

du cas) et le systme. La description de linteraction est ralise suivant le point de
vue de lutilisateur.
La reprsentation dun cas dutilisation met en jeu trois concepts : lacteur, le cas
dutilisation et linteraction entre lacteur et le cas dutilisation.
Acteur
Un acteur est un utilisateur type qui a toujours le mme comportement vis--vis
dun cas dutilisation. Ainsi les utilisateurs dun systme appartiennent une ou
plusieurs classes dacteurs selon les rles quils tiennent par rapport au systme.
Une mme personne physique peut se comporter en autant dacteurs diffrents
que le nombre de rles quelle joue vis--vis du systme.
Ainsi par exemple, ladministrateur dun systme de messagerie peut tre aussi
utilisateur de cette mme messagerie. Il sera considr, en tant quacteur du systme,
dans le rle dadministrateur dune part et dans celui dutilisateur dautre part.
Un acteur peut aussi tre un systme externe avec lequel le cas dutilisation va
interagir.
Un acteur peut se reprsenter symboliquement par un bonhomme et tre iden-
tifi par son nom. Il peut aussi tre formalis par une classe strotype acteur
(fig. 3.1).
acteur
Nom de lacteur
Figure 3.1 Reprsentations dun acteur
Cas dutilisation et interaction

Un cas dutilisation correspond un certain nombre dactions que le systme devra
excuter en rponse un besoin dun acteur. Un cas dutilisation doit produire un
rsultat observable pour un ou plusieurs acteurs ou parties prenantes du systme.
Une interaction permet de dcrire les changes entre un acteur et un cas dutili-
sation.
3.1 Diagramme des cas dutilisation (DCU) 63
Un cas dutilisation se reprsente par un ovale dans lequel figure son intitul.
Linteraction entre un acteur et un cas dutilisation se reprsente comme une
association. Elle peut comporter des multiplicits comme toute association entre
classes (voir 2.1 Diagramme de classe).
Le formalisme de base de reprsentation dun cas dutilisation est donn la
figure 3.2.
Interaction
Nom du cas
dutilisation
Nom de lacteur
Figure 3.2 Formalisme de base de reprsentation dun cas dutilisation
Chaque cas dutilisation doit tre dcrit sous forme textuelle afin de bien identi-
fier les traitements raliser par le systme en vue de la satisfaction du besoin
exprim par lacteur.
3.1.2 Reprsentation du diagramme des cas dutilisation

Tout systme peut tre dcrit par un certain nombre de cas dutilisation correspon-
dant aux besoins exprims par lensemble des utilisateurs. chaque utilisateur, vu
comme acteur, correspondra un certain nombre de cas dutilisation du systme.
Lensemble de ces cas dutilisation se reprsente sous forme dun diagramme.
Exemple
La figure 3.3 montre un exemple dun systme de messagerie comportant quatre cas
dutilisation.
Nous verrons, dans la suite de la prsentation dUML, quun cas dutilisation peut
avoir une ou plusieurs instances reprsentes par des scnarios. Chaque scnario
fait lobjet lui-mme dun diagramme de squence ou de communication.
En conclusion, nous dirons quun systme est caractris par son comportement
vis--vis de ses utilisateurs. Ce comportement se reprsente sous forme dun en-
semble de cas dutilisation qui correspond aux besoins des acteurs de ce systme.
Systme de messagerie
1 *
Connexion
1
Acteur A
1 *
Lecture bote
1
Envoi dun message
1
*
*
Changement de droit Administrateur
Figure 3.3 Exemple dun systme de messagerie

comportant quatre cas dutilisation
3.1.3 Relations entre cas dutilisation

Afin doptimiser la formalisation des besoins en ayant recours notamment la ruti-
lisation de cas dutilisation, trois relations peuvent tre dcrites entre cas
dutilisation : une relation dinclusion ( include ), une relation dextension
( extend ) et une relation de gnralisation.
Relation dinclusion
Une relation dinclusion dun cas dutilisation A par rapport un cas dutilisation B
signifie quune instance de A contient le comportement dcrit dans B.
La figure 3.4 donne le formalisme et un exemple dune relation dinclusion entre cas
dutilisation.
Cas A
include
Cas B
include
Cas C
Les cas A et C
ont recours au cas B
1
* include
Cration
dun nouvel abonn Contrle paiement
abonnement
Gestionnaire
Figure 3.4 Formalisme et exemple de la relation dinclusion

entre cas dutilisation
Relation dextension
Une relation dextension dun cas dutilisation A par un cas dutilisation B signifie
quune instance de A peut tre tendue par le comportement dcrit dans B. Deux
caractristiques sont noter :
le caractre optionnel de lextension dans le droulement du cas dutilisation
standard (A) ;
la mention explicite du point dextension dans le cas dutilisation standard.
La figure 3.5 donne un exemple dune relation dextension entre cas dutilisation.
Une note peut tre ajoute la reprsentation du cas dutilisation permettant
dexpliciter la condition.
Relation de gnralisation
Une relation de gnralisation de cas dutilisation peut tre dfinie conformment
au principe de la spcialisation-gnralisation dj prsente pour les classes.
La figure 3.6 donne un exemple dune relation de gnralisation de cas dutilisation.
extend Cas A
Cas B
Point d'extension : X
Servir
boisson chaude
1 *
Point dextension : X
Condition :
Client {si plus de sucre}
extend Point dextension : X
Servir
supplment sucre
Figure 3.5 Formalisme et exemple dune relation dextension

entre cas dutilisation
1 *
Retirer argent
Client
Retirer des euros Retirer des dollars
Figure 3.6 Exemple dune relation de gnralisation de cas dutilisation
3.1.4 Description textuelle dun cas dutilisation

chaque cas dutilisation doit tre associe une description textuelle des interac-
tions entre lacteur et le systme et les actions que le systme doit raliser en vue de
produire les rsultats attendus par les acteurs.
UML ne propose pas de prsentation type de cette description textuelle. Cepen-
dant, les travaux mens par Alistair Cockburn [Cockburn2001] sur ce sujet consti-
tuent une rfrence en la matire et tout naturellement nous reprenons ici lessentiel
de cette prsentation.
La description textuelle dun cas dutilisation est articule en six points :

Objectif Dcrire succinctement le contexte et les rsultats attendus du cas
dutilisation.
Acteurs concerns Le ou les acteurs concerns par le cas doivent tre iden-
tifis en prcisant globalement leur rle.
Pr conditions Si certaines conditions particulires sont requises avant
lexcution du cas, elles sont exprimer ce niveau.
Post conditions Par symtrie, si certaines conditions particulires doivent
tre runies aprs lexcution du cas, elles sont exprimer ce niveau. Pour
notre part, par souci de simplification nous navons pas trait ce point dans les
exercices et tudes de cas prsents.
Scnario nominal Il sagit l du scnario principal qui doit se drouler sans
incident et qui permet daboutir au rsultat souhait.
Scnarios alternatifs Les autres scnarios, secondaires ou correspondant la
rsolution danomalies, sont dcrire ce niveau. Le lien avec le scnario
principal se fait laide dune numrotation hirarchise (1.1a, 1.1b) rappe-
lant le numro de laction concerne.
3.1.5 Exercices
Exercice 1
nonc
Une bibliothque universitaire souhaite automatiser sa gestion. Cette bibliothque
est gre par un gestionnaire charg des inscriptions et des relances des lecteurs
quand ceux-ci nont pas rendu leurs ouvrages au-del du dlai autoris. Les biblio-
thcaires sont chargs de grer les emprunts et la restitution des ouvrages ainsi que
lacquisition de nouveaux ouvrages.
Il existe trois catgories dabonn. Tout dabord les tudiants qui doivent seule-
ment sacquitter dune somme forfaitaire pour une anne afin davoir droit tous les
services de la bibliothque. Laccs la bibliothque est libre pour tous les ensei-
gnants. Enfin, il est possible dautoriser des tudiants dune autre universit sins-
crire exceptionnellement comme abonn moyennant le versement dune cotisation.
Le nombre dabonn externe est limit chaque anne environ 10 % des inscrits.
Un nouveau service de consultation du catalogue gnral des ouvrages doit tre
mis en place.
Les ouvrages, souvent acquis en plusieurs exemplaires, sont rangs dans des
rayons de la bibliothque. Chaque exemplaire est repr par une rfrence gre
dans le catalogue et le code du rayon o il est rang.
Chaque abonn ne peut emprunter plus de trois ouvrages. Le dlai demprunt
dun ouvrage est de trois semaines, il peut cependant tre prolong exceptionnelle-
ment cinq semaines.
Il est demand dlaborer le diagramme des cas dutilisation (DCU).
Corrig
Reprsentation du DCU La figure 3.7 propose un corrig-type de cet exercice. Six
cas dutilisation peuvent tre identifis :
inscription la bibliothque,
consultation du catalogue,
emprunt douvrages,
restitution douvrages,
approvisionnement douvrages,
relance emprunteur.
Comme le montre la figure 3.7, cinq types dacteurs peuvent tre identifis :
tudiant,
externe,
emprunteur,
gestionnaire,
bibliothcaire.
tudiant
S'inscrire include
Paiement
des droits
Externe
Consulter catalogue
Gestionnaire
Emprunter ouvrage
Emprunteur
Rendre ouvrage
Approvisionner ouvrage
Bibliothcaire
Relancer
Figure 3.7 Corrig type de lexercice 1 sur les cas dutilisation

Exercice de synthse
En reprenant lnonc de lexercice de synthse Locagite, nous allons laborer le
diagramme des cas dutilisation des quatre activits dcrites :
Catalogue, cette activit se dcompose en trois cas dutilisation :
cas dutilisation 1.1 : Gestion annuelle du catalogue
cas dutilisation 1.2 : Publication du catalogue
cas dutilisation 1.3 : Contrle annuel de ltat du gte
Propritaire, cette activit se dcompose en deux cas dutilisation :
cas dutilisation 2.1 : Gestion propritaire
cas dutilisation 2.2 : Authentification propritaire
Rservation, cette activit dcompose en deux cas dutilisation :
cas dutilisation 3.1 : Gestion des rservations
cas dutilisation 3.2 : Authentification client
Location, cette activit se dcompose en deux cas dutilisation :
cas dutilisation 4.1 : Gestion des locations
cas dutilisation 4.2 : Gestion des annulations
Pour ces cas dutilisation considrs, quatre acteurs types externes peuvent tre
identifis :
le propritaire,
le propritaire adhrent (qui met en location son gte),
le client rservataire,
le client locataire.
Deux acteurs internes peuvent tre identifis :

le gestionnaire Catalogue-Propritaire,
le gestionnaire Rservation-Location.
Le diagramme de ces cas dutilisation est donn la figure 3.8.
Dans le cadre de cet exercice de synthse, nous nous limiterons donner la description
textuelle des scnarios des cas dutilisation de lactivit catalogue (cas 1.1, 1.2 et 1.3).
Cas dutilisation 1.1 : Gestion annuelle du catalogue

Deux scnarios peuvent tre considrs : la cration du gte et la modification du gte.
Scnario 1.1.1 Cration gte
Objectif Permettre lajout dun gte dans le catalogue.
Acteurs concerns Gestionnaire catalogue.
Pr conditions Aucune.
Scnario nominal
1. Crer un nouveau propritaire sil nexiste pas.
2. Crer un gte.
3. Ajouter le gte cr au catalogue.
Scnarios alternatifs
1-a : Erreurs dtectes dans la saisie du propritaire :
Le systme raffiche le formulaire de saisie en indiquant les erreurs dtectes.
Le coordonnateur corrige les erreurs.
Le cas dutilisation reprend laction 1 du scnario nominal.
2-a : Erreurs dtectes dans la saisie du gte :
1.1 Gestion annuelle du catalogue
Gestionnaire catalogue
Propritaire
<<extend>>
<<extend>>
<<include>
1.2 Publication catalogue 1.3 Mise jour annuelle gte
2.2 Authentification propritaire
<<include>>
2.1 Gestion propritaire
Propritaire adhrent
3.1 Gestion rservation
Client rservataire Gestionnaire rservation
<<include>> <<extend>>
3.2 Authentification client 4.2 Gestion annulation
<<extend>>
<<include>>
4.1 Gestion location
Client locataire
Figure 3.8 Diagramme des cas dutilisation de Locagite

Scnario 1.1.2 Modification gte

Objectif Permettre la modification dun gte dj prsent dans le catalogue.
Scnario nominal
1. Saisie et contrle dexistence du gte.
2. Saisie et contrle dexistence du propritaire.
3. Modification des donnes du gte.
4. Modification ventuelle des activits du gte,
1-a : Erreur de saisie du gte :
Le systme raffiche le formulaire de saisie en indiquant lerreur dtecte.
2-a : Erreurs de saisie du propritaire :
Cas dutilisation 1.2 : Publication du catalogue

Ce cas dutilisation ne comporte quun seul scnario.
Scnario Publication du catalogue
Objectif Permettre ldition du catalogue.
Scnario nominal Pour chaque gte :
1. Rechercher les informations sur le propritaire.
2. Afficher les tarifs de location la semaine.
3. Afficher les activits disponibles.
Scnarios alternatifs Aucun.
Cas dutilisation 1.3 : Mise jour annuelle du gte

Ce cas dutilisation ne comporte quun seul scnario.
Scnario Mise jour annuelle du gte
Objectif Permettre la mise jour du nombre dtoile dun gte donn.
Scnario nominal :
1. Saisir le code propritaire, le code du gte et le nombre dtoile.
2. Mettre jour le nombre dtoile.
Scnarios alternatifs :
1-a : le propritaire ou le gte nexiste pas :
Le systme raffiche le formulaire de saisie en indiquant lerreur dtecte.
Le gestionnaire corrige les erreurs.
3.2 DIAGRAMME DTAT-TRANSITION (DET)

tat-transition et vnement
Ltat dun objet est dfini, un instant donn, par lensemble des valeurs de ses
proprits. Seuls certains tats caractristiques du domaine tudi sont considrs.
Le passage dun tat un autre tat sappelle transition. Un vnement est un
fait survenu qui dclenche une transition.
Il existe quatre types dvnements :
Type appel de mthode (call) Cest le type le plus courant que nous traite-
rons dans la suite de la prsentation.
Type signal Exemple : clic de souris, interruption dentres-sorties La
modlisation de la rception ou lmission dun signal est traite dans le
diagramme dactivit.
Type changement de valeur (vrai/faux) Cest le cas de lvaluation dune
expression boolenne.
Type coulement du temps Cest un vnement li une condition de type
after (dure) ou when (date).
Un objet reste dans un tat pendant une certaine dure. La dure dun tat corres-
pond au temps qui scoule entre le dbut dun tat dclench par une transition i et
la fin de ltat dclench par la transition i+1. Une condition, appele garde ,
peut tre associe une transition.
Le formalisme de reprsentation dtat-transition est donn la figure 3.9.
vnement [condition] tat

tat
1 2
Figure 3.9 Formalisme dtat-transition

3.2 Diagramme dtat-transition (DET) 73
La figure 3.10 donne un premier exemple dtat-transition. Dans cet exemple,

pour un employ donn dune entreprise, nous pouvons considrer les deux tats
significatifs suivants : tat recrut, tat en activit.
Candidature
accepte Prise de fonction [date d'embauche chue]
Employ Employ
recrut en activit
Figure 3.10 Exemple dtat-transition
Action et activit
Une action est une opration instantane qui ne peut tre interrompue ; elle est
associe une transition.
Une activit est une opration dune certaine dure qui peut tre interrompue,
elle est associe un tat dun objet.
Le formalisme de reprsentation dtat-transition comprenant la reprsentation
daction et/ou activit est donn la figure 3.11.
tat 1 vnement [condition]/action tat 2

Faire activit 1 Faire activit 2
Figure 3.11 Formalisme dtat-transition avec action et activit
La figure 3.12 montre un exemple des actions et activits dtats ainsi que la des-
cription complte dune transition.
tat 1 tat 2
Maladie [avec arrt]/mise en arrt
faire : travaille faire : mise en arrt
Figure 3.12 Exemple dtat-transition avec action et activit
3.2.2 Reprsentation du diagramme dtat-transition dun objet

Lenchanement de tous les tats caractristiques dun objet constitue le diagramme
dtat. Un diagramme dtats dbute toujours par un tat initial et se termine par un
ou plusieurs tats finaux sauf dans le cas o le diagramme dtats reprsente une
boucle. un vnement peut tre associ un message compos dattributs.
Le formalisme de reprsentation des tats initial et final est donn la figure 3.13.
vnement 1 [condition 1]/action 1 vnement 2 [condition 2]/action 2...
tat 1 tat 4
tat 2 tat 3
initial final
Figure 3.13 Formalisme de reprsentation des tats initial et final
Afin de nous rapprocher des situations relles, nous proposons la figure 3.14 un
premier exemple tir dune gestion commerciale qui montre le diagramme dtat-
transition de lobjet client.
re
Passer 1 commande Non-paiement Limite
financire
Client dpasse
Client Client
prospect actif douteux
Paiement
Client
Ne passe plus en contentieux
commande
Client Client
inactif supprim
Fin du
Une anne
contentieux
sans commande
Figure 3.14 Diagramme dtat-transition de lobjet client dune gestion commerciale
Nous proposons comme second exemple, la figure 3.15, le diagramme dtat-

transition de lobjet personnel qui se caractrise par trois tats :
En prvision darrive : si la date prvisionnelle est postrieure la date du
jour.
En activit : tat qui correspond un personnel ayant une date darrive
renseigne.
Parti : tat qui correspond un personnel ayant une date de dpart rensei-
gne.
Ordre de recrutement dun personnel [date-prvisionnelle > date du jour]/crer ( )
En prvision
darrive
Prise de fonction
En activit
Action : renseigner la date

darrive lagence
Dpart de lagence
Parti
Action : renseigner la date

de dpart de la personne
Figure 3.15 Exemple de diagramme dtat-transition
3.2.3 Complments sur le diagramme dtat-transition

Composition et dcomposition dtat
Il est possible de dcrire un diagramme dtat-transition plusieurs niveaux. Ainsi,
un premier niveau, le diagramme comprendra des tats lmentaires et des tats
composites. Les tats composites seront ensuite dcrits un niveau lmentaire
dans un autre diagramme. On peut aussi parler dtat compos et dtat composant.
Le formalisme de reprsentation dtats composites est donn la figure 3.16.
enregistr/contrler contrl/dcider
Reu Contrl Accept
Symbole de reprsentation
dun tat composite
Dtail de ltat contrler feuille

composite
contrle nSS contrle des droits
Figure 3.16 Exemple dtat composite

Dans cet exemple, ltat contrl est un tat composite qui fait lobjet dune des-
cription individualise un second niveau que lon appelle aussi sous-machine dtat.
Point dentre et de sortie

Sur une sous-machine dtat, il est possible de reprer un point dentre et un point
de sortie particuliers.
Le formalisme de reprsentation dune sous-machine dtat avec point dentre et de
sortie est donn la figure 3.17.
Sortie tat aval

standard
tat amont Sous-machine d'tat
Anomalie
Entre
standard
Point d'entre (particulier ou standard) Point de sortie (particulier)
Figure 3.17 Exemple dune sous-machine dtat avec point dentre et de sortie
Point de jonction
Lorsque lon veut relier plusieurs tats vers dautres tats, un point de jonction
permet de dcomposer une transition en deux parties en indiquant si ncessaire les
gardes propres chaque segment de la transition.
lexcution, un seul parcours sera emprunt, cest celui pour lequel toutes les
conditions de garde seront satisfaites.
Le formalisme de reprsentation dtats-transitions avec point de jonction est donn
la figure 3.18.
Point de choix
Le point de choix se comporte comme un test de type : si condition faire action1
sinon faire action2.
Le formalisme de reprsentation dtats composites est donn la figure 3.19.
Point de jonction
message vocal A/R

reu message vocal
[typeMessage = vocal]
message SMS [typeMessage = SMS] A/R

reu message SMS
[typeMessage = Fax]
message Fax A/R
reu message Fax
Figure 3.18 Exemple dtats-transitions avec point de jonction
Point de choix
message vocal message mobile reu/activerA/R

reu
A/R mobile
message mobile reu/activerA/R [typeMobile]

message SMS
reu
[else]
A/R Fax
message Fax message Fax reu/activerA/R
reu
Figure 3.19 Exemple dtats-transitions avec point de choix

tat historique
La mention de lhistorisation dun tat composite permet de pouvoir indiquer la
rutilisation du dernier tat historis en cas de besoin.
Le formalisme de reprsentation dtats historiss est donn la figure 3.20.
H tat historis
Programme Lavage
Lavage Rinage Essorage
remise en marche
arrt/mise en marche
Figure 3.20 Exemple dtats-transitions historiss
3.2.4 Exercices
Exercice 1
nonc
Soit reprsenter le diagramme dtat-transition dun objet personnel en suivant les
vnements de gestion depuis le recrutement jusqu la mise en retraite.
Aprs le recrutement, une personne est considre en activit ds sa prise de
fonction dans lentreprise. Au cours de sa carrire, nous retiendrons seulement les
vnements : cong de maladie et prise de cong annuel. En fin de carrire, nous
retiendrons deux situations : la dmission et la retraite.
Corrig
Nous proposons au lecteur un corrig type la figure 3.21. Ce corrig ne reprsente
quune solution parmi dautres variantes possibles suivant la lecture faite de
lnonc. Pour notre part, nous avons retenu les tats caractristiques : recrut, acti-
vit, en cong, en arrt, parti et retraite.
retraite
Demande de retraite [ge]/mise en retraite
Maladie/mise en maladie
Arrive/prise de fonction
recrut activit en arrt
Reprise/reprise activit
Retour
Dmission/dpart cong/mise
en activit Prise de cong/mise en cong
parti en cong
Figure 3.21 Diagramme dtat-transition de lexercice 1
Exercice de synthse
En se replaant dans lexercice de synthse Locagite, nous allons retenir lobjet
Gtes grs comme support dapplication du diagramme dtat-transition. Quatre
tats permettent de caractriser son comportement :
tat 1 : Gte louer
tat 2 : Gte rserv
tat 3 : Gte rserv ferme
tat 4 : Gte rserv lou
La figure 3.22 reprsente le diagramme dtat-transition de cet objet.

annulation sjour
cration rservation
Gte louer rserv
acompte
pas acompte
rserv
ferme
annulation sjour
solde
pas solde
location
lou
Figure 3.22 Diagramme dtat-transition de lobjet Gtes grs
3.3 DIAGRAMME DACTIVIT (DAC)

Le diagramme dactivit prsente un certain nombre de points communs avec le
diagramme dtat-transition puisquil concerne le comportement interne des opra-
tions ou des cas dutilisation. Cependant le comportement vis ici sapplique aux
flots de contrle et aux flots de donnes propres un ensemble dactivits et non
plus relativement une seule classe.
Les concepts communs ou trs proches entre le diagramme dactivit et le dia-
gramme dtat-transition sont :
transition,
nud initial (tat initial),
nud final (tat final),
nud de fin flot (tat de sortie),
nud de dcision (choix).
Le formalisme reste identique pour ces nuds de contrle.

3.3 Diagramme dactivit (DAC) 81
Les concepts spcifiques au diagramme dactivit sont :

nud de bifurcation,
nud de jonction,
nud de fusion,
pin dentre et de sortie,
flot dobjet,
partition.
Nous avons par ailleurs rserv un traitement particulier pour les concepts action
et activit. En effet, tant donn que ces concepts sont au cur du diagramme
dactivit, nous avons prfr les traiter de manire dtaille ce niveau alors
quils sont dj voqus dans le diagramme dtat-transition.
Action
Une action correspond un traitement qui modifie ltat du systme. Cette action
peut tre apprhende soit un niveau lmentaire proche dune instruction en
termes de programmation soit un niveau plus global correspondant une ou
plusieurs oprations.
Une action est reprsente par un rectangle dont les coins sont arrondis comme pour
les tats du diagramme dtat-transition (fig. 3.23).
Nom de laction Saisir commande
Figure 3.23 Formalisme et exemple dune action
Transition et flot de contrle

Ds quune action est acheve, une transition automatique est dclenche vers
laction suivante. Il ny a donc pas dvnement associ la transition.
Lenchanement des actions constitue le flot de contrle.
Le formalisme de reprsentation dune transition est donn la figure 3.24.
transition
action 1 action 2
Figure 3.24 Formalisme de base du diagramme dactivit : actions et transition

Activit
Une activit reprsente le comportement dune partie du systme en termes
dactions et de transitions. Une activit est compose de trois types de nuds :
nud dexcution (action, transition),
nud de contrle (nud initial, nud final, flux de sortie, nud de bifurca-
tion, nud de jonction, nud de fusion-test, nud de test-dcision, pin
dentre et de sortie),
nud dobjet.
Une activit peut recevoir des paramtres en entre et en produire en sortie.

Nous donnons une premire reprsentation simple la figure 3.25.
activit : Traiter commande
Saisir Contrler diter

commande commande commande
Figure 3.25 Exemple de reprsentation dune activit
Nud de bifurcation (fourche)

Un nud de bifurcation (fourche) permet partir dun flot unique entrant de crer
plusieurs flots concurrents en sortie de la barre de synchronisation.
Le formalisme de reprsentation de nud de bifurcation ainsi quun premier
exemple sont donns la figure 3.26. Un second exemple avec nud de bifurcation
est donn la figure 3.27.
Nud de bifurcation
(fourche)
rception paiement
compatibiliser envoyer marchandise
Figure 3.26 Exemple 1 dactivits avec nud de bifurcation
Examen
candidature Points
de bifurcation
Lettre de refus Convocation
Prparation Prparation
entretien technique entretien DRH
Figure 3.27 Exemple 2 de diagramme dactivit

avec bifurcation de flots de contrle
Nud de jonction (synchronisation)

Un nud de jonction (synchronisation) permet, partir de plusieurs flots concur-
rents en entre de la synchronisation, de produire un flot unique sortant. Le nud
de jonction est le symtrique du nud de bifurcation.
Le formalisme de reprsentation dun nud de jonction est donn la figure 3.28.
Nud de jonction
(synchronisation)
inscrire adhrent enregistrer cotisation
envoyer carte adhrent
Figure 3.28 Exemple dactivits avec nud de jonction
Nud de test-dcision
Un nud de test-dcision permet de faire un choix entre plusieurs flots sortants en
fonction des conditions de garde de chaque flot. Un nud de test-dcision na quun
seul flot en entre. On peut aussi utiliser seulement deux flots de sortie : le premier
correspondant la condition vrifie et lautre traitant le cas sinon.
Le formalisme de reprsentation dun nud de test-dcision ainsi quun premier
exemple sont donns la figure 3.29. Un second exemple avec nud de test-dci-
sion est donn la figure 3.30.
symbole du nud de dcision-test
Facturer particulier
[particulier]
Saisir
commande
[grossiste] Facturer grossiste
Figure 3.29 Formalisme et exemple 1 dactivits avec nud de test-dcision

Examen
candidature
[Candidature rejete] [Candidature retenue]
Lettre de refus Convocation
Transition
Entretien
Figure 3.30 Exemple 2 de diagramme dactivits avec un nud de test-dcision
Nud de fusion-test
Un nud de fusion-test permet davoir plusieurs flots entrants possibles et un seul
flot sortant. Le flot sortant est donc excut ds quun des flots entrants est activ.
Le formalisme de reprsentation dun nud de fusion-test ainsi quun exemple sont
donns la figure 3.31.
Nud de fusion-test
Commander
par tlphone
Commander
Facturer
par messagerie
Commander
par courrier
Figure 3.31 Formalisme et exemple de diagramme dactivits

avec un nud de fusion-test
Pin dentre et de sortie

Un pin dentre ou de sortie reprsente un paramtre que lon peut spcifier en
entre ou en sortie dune action. Un nom de donne et un type de donne peuvent
tre associs au pin. Un paramtre peut tre de type objet.
Chaque paramtre se reprsente dans un petit rectangle. Le nom du paramtre ainsi
que son type sont aussi indiquer. Le formalisme de reprsentation de pin dentre
ou de sortie ainsi quun exemple sont donns la figure 3.32.
pin dentre ou de sortie
facturer
p1
r1
p2
p1 : entier
p2 : texte
r1 : rel
Figure 3.32 Formalisme et exemple dactivit avec pin dentre et de sortie
Flot de donnes et nud dobjet

Un nud dobjet permet de reprsenter le flot de donnes vhicul entre les
actions. Les objets peuvent se reprsenter de deux manires diffrentes : soit en utili-
sant le pin dobjet soit en reprsentant explicitement un objet.
Le formalisme de reprsentation de flot de donnes et nud dobjet est donn direc-
tement au travers dun exemple (fig. 3.33).
Commander Facturer
: commande : commande
Commander Facturer
[commande]
Figure 3.33 Exemple de flot de donnes et de nud dobjets

Partition
UML permet aussi dorganiser la prsentation du diagramme dactivit en couloir
dactivits. Chaque couloir correspond un domaine de responsabilit dun certain
nombre dactions.
Les flots dobjets sont aussi reprsents dans le diagramme. Lordre relatif des cou-
loirs de responsabilit nest pas significatif.
3.3.2 Reprsentation du diagramme dactivit

Un exemple gnral de diagramme dactivit est donn la figure 3.34.
Client Service commercial Stock
Demander produit
Rechercher produit Contrler stock
Commander
Enregistrer commande
crer
[Commande]
Facturer
crer
[Facture]
Figure 3.34 Exemple de diagramme dactivit avec couloir dactivit
Reprsentation dactions de communication

Dans un diagramme dactivit, comme dans un diagramme de temps, des interac-
tions de communication lies certains types dvnement peuvent se reprsenter.
Les types dvnement concerns sont :
signal,
coulement du temps.
Le formalisme de reprsentation ainsi quun exemple dactions de communication
sont donns la figure 3.35.
Signal reu
Acceptation dune condition

lie au temps
Signal envoy
Dtecter arrive vhicule
Actionner ouverture
Ouvrir portes Faire clignoter lampe
Figure 3.35 Formalisme et exemple de diagramme dactivit

avec actions de communication
3.3.3 Exercices
Exercice 1
En reprenant lexercice relatif la gestion de la bibliothque trait dans les cas
dutilisation nous pouvons laborer le diagramme dactivit correspondant.
Deux acteurs ont t identifis :
Bibliothcaire charg de lapprovisionnement des ouvrages, de la gestion du
catalogue et de lenregistrement des emprunts et retours douvrages ;
Gestionnaire, charg de linscription des adhrents et de la relance des adh-
rents ayant dpass le dlai de restitution des ouvrages.
La reprsentation du diagramme dactivit est donne la figure 3.36.

Gestionnaire Bibliothcaire
inscrire adhrent acqurir ouvrage
[ouvrage]
[adhrent]
mettre jour catalogue
enregistrer emprunt/retour
[ si pas adhrent ] [ anomalies ]

contrler dpassement dlai
[ dlai dpass ]
[ dlai dpass ]
relancer adhrent
Figure 3.36 Diagramme dactivit de lexercice 1
Exercice de synthse
La figure 3.37 reprsente le diagramme dactivit de Locagite. Ce diagramme nous
permet de montrer, par couloir de responsabilit des acteurs internes Locagite, les
tats-actions excuts.
Gestionnaire catalogue-propritaire Gestionnaire rservation-location
enregistrer rservations
enregistrer nouveau gte
diter tat contrat

enregistrer contrat propritaire
mettre jour catalogue enregistrer conf. contrat et acompte
mettre jour gte contrler dlai confirmation
[ dlai dpass ]
diter catalogue
[ arrive solde ]
annuler contrat
diter tat des rservations

enregistrer annulation contrat
enregistrer solde
Figure 3.37 Diagramme dactivit du cas Locagite
3.4 DIAGRAMME DE SQUENCE (DSE)

Lobjectif du diagramme de squence est de reprsenter les interactions entre objets
en indiquant la chronologie des changes. Cette reprsentation peut se raliser par
cas dutilisation en considrant les diffrents scnarios associs.
3.4 Diagramme de squence (DSE) 91
Un diagramme de squence se reprsente globalement dans un grand rectangle

avec indication du nom du diagramme en haut gauche comme indiqu la
figure 3.38.
sd nom du diagramme
reprsentation du diagramme
sd : abrviation de sequence diagramm
Figure 3.38 Formalisme gnral du cadre dun diagramme de squence
Ligne de vie
Une ligne de vie reprsente lensemble des oprations excutes par un objet. Un
message reu par un objet dclenche lexcution dune opration. Le retour dinfor-
mation peut tre implicite (cas gnral) ou explicite laide dun message de retour.
Message synchrone et asynchrone

Dans un diagramme de squence, deux types de messages peuvent tre distingus :
Message synchrone Dans ce cas lmetteur reste en attente de la rponse
son message avant de poursuivre ses actions. La flche avec extrmit pleine
symbolise ce type de message. Le message retour peut ne pas tre reprsent
car il est inclus dans la fin dexcution de lopration de lobjet destinataire du
message. Voir le message 1 de la figure 3.39.
Message asynchrone Dans ce cas, lmetteur nattend pas la rponse son
message, il poursuit lexcution de ses oprations. Cest une flche avec une
extrmit non pleine qui symbolise ce type de message. Voir le message 2 de la
figure 3.39.
Le formalisme est donn dans lexemple type prsent la figure 3.39.
3.4.2 Oprations particulires

Cration et destruction dobjet
Si un objet est cr par une opration, celui-ci napparat quau moment o il est
cr. Si lobjet est dtruit par une opration, la destruction se reprsente par X .
Un exemple type est donn la figure 3.40.
sd Diagramme 1
objet1 objet2 objet3
: Client Ligne de vie

message 1()
message 2()
message 3
message 4
message 5()
retour message3
Figure 3.39 Formalisme du diagramme de squence
objet 1 : Classe 1
Cration objet 2
objet 2 : Classe 2
Destruction objet 2
Figure 3.40 Exemple type de cration et de destruction dobjet
Il est aussi possible dans certains outils de modlisation dindiquer plus simple-
ment la cration dune nouvelle instance dobjet en utilisant le mot-cl create
(voir exemple dans les tudes de cas prsentes la fin de cet ouvrage).
Contrainte temporelle
Des contraintes de chronologie entre les messages peuvent tre spcifies. De plus lorsque
lmission dun message requiert une certaine dure, il se reprsente sous la forme dun
trait oblique. Un exemple gnral de contrainte temporelle est donn la figure 3.41.
Lorsque le diagramme de squence est utilis pour reprsenter un sous-ensemble
du logiciel raliser, il est possible dindiquer le pseudo-code excut par un objet
pendant le droulement dune opration.
objet 1 : Classe 1 objet 2 : Classe 2
{b-a < 2 sec.}

b
Figure 3.41 Exemple type de reprsentation de contrainte temporelle
3.4.3 Fragment dinteraction

Types de fragments dinteraction
Dans un diagramme de squence, il est possible de distinguer des sous-ensembles
dinteractions qui constituent des fragments.
Un fragment dinteraction se reprsente globalement comme un diagramme de
squence dans un rectangle avec indication dans le coin gauche du nom du frag-
ment.
Un port dentre et un port de sortie peuvent tre indiqus pour connatre la
manire dont ce fragment peut tre reli au reste du diagramme comme le montre la
figure 3.42. Dans le cas o aucun port nest indiqu cest lensemble du fragment qui
est appel pour excution.
Dans lexemple propos (fig. 3.42), le fragment ContrlerProduit est reprsent
avec un port dentre et un port de sortie.
Un fragment dinteraction dit combin correspond un ensemble dinteraction
auquel on applique un oprateur. Un fragment combin se reprsente globalement
comme un diagramme de squence avec indication dans le coin gauche du nom de
loprateur.
Treize oprateurs ont t dfinis dans UML : alt, opt, loop, par, strict/weak, break, ignore/
consider, critical, negative, assertion et ref.
sd Diagramme densemble
Interface
IHM Client
: Gestionnaire
saisirCommande( )
contrlerClient( )
seq ContrlerProduit
Produit
contrlerExistenceProduit
existeProduit( )
Figure 3.42 Exemple de fragment dinteraction avec port dentre et de sortie
Oprateur alt
Loprateur alt correspond une instruction de test avec une ou plusieurs alterna-
tives possibles. Il est aussi permis dutiliser les clauses de type sinon.
Loprateur alt se reprsente dans un fragment possdant au moins deux parties spa-
res par des pointills. Lexemple donn (fig. 3.43) montre lquivalent dun test
deux conditions explicites (sans clause sinon).
Oprateur opt
Loprateur opt (optional) correspond une instruction de test sans alternative (sinon).
Loprateur opt se reprsente dans un fragment possdant une seule partie (fig. 3.44).
Oprateur loop
Loprateur loop correspond une instruction de boucle qui permet dexcuter une
squence dinteraction tant quune condition est satisfaite.
Il est possible aussi dutiliser une condition portant sur un nombre minimum et
maximum dexcution de la boucle en crivant : loop min, max. Dans ce cas, la bou-
cle sexcutera au minimum min fois et au maximum max fois. Il est aussi possible de
combiner loption min/max avec la condition associe la boucle.
: Adhrent : Emprunt
: Gestionnaire
saisirAdhrent( ) contrlertat( )
alt tatEmprunt
[tat emprunt=rendu]
autoriserEmprunt( )
[tat emprunt=non rendu]

refuserEmprunt( )
Figure 3.43 Exemple de fragment dinteraction avec loprateur alt
: Adhrent : Emprunt
: Gestionnaire
relancer( )
testerArelancer( )
retourSituationRelance
opt Relancer [si relance]
relancer( )
Figure 3.44 Exemple de fragment dinteraction avec loprateur opt
Loprateur loop se reprsente dans un fragment possdant une seule partie et englo-
bant toutes les interactions faisant partie de la boucle. Un exemple est donn la
figure 3.45.
: Association : Adhrent
loop tatRetour=Non rendu et dlai= dpass

relancer( )
Figure 3.45 Exemple de fragment dinteraction avec loprateur loop
Oprateur par
Loprateur par (parallel) permet de reprsenter deux sries dinteractions qui se
droulent en parallle.
Loprateur par se reprsente dans un fragment possdant deux parties spares par
une ligne en pointill. Cest un oprateur qui est notre avis plutt utilis dans
linformatique temps rel et cest pour cela que nous ne donnerons quun exemple
type (fig. 3.46).
: Classe1 : Classe2 : Classe3
Traitements A1 et A2 mens
en parallle au traitement B3
par traiterA1( )
traiterA2( )
traiterB3( )
Figure 3.46 Exemple de fragment dinteraction avec loprateur par

Oprateurs strict et weak sequencing

Les oprateurs srict et weak permettent de reprsenter une srie dinteractions dont
certaines soprent sur des objets indpendants :
Loprateur strict est utilis quand lordre dexcution des oprations doit tre
strictement respect.
Loprateur weak est utilis quand lordre dexcution des oprations na pas
dimportance.
Lexemple prsent figure 3.47 montre que les oprations A1, A2, B1, B2 et A3
doivent tre excutes dans cet ordre puisquelles font partie du fragment dinterac-
tion comportant loprateur strict.
: Classe1 : Classe2 : Classe3 : Classe4
strict
traiterA1( )
traiterA2( )
traiterB1( )
traiterB2( )
traiterA3( )
Figure 3.47 Exemple de fragment dinteraction avec loprateur strict
Oprateur break
Loprateur break permet de reprsenter une situation exceptionnelle correspondant
un scnario de rupture par rapport au scnario gnral. Le scnario de rupture
sexcute si la condition de garde est satisfaite.
Lexemple prsent figure 3.48 montre que les oprations annulerOp1( ),
annulerOp2( ) et afficherAide( ) ne seront excutes que si la touche F1 est active
sinon le fragment est ignor et la squence de traitement passe directement de
lopration Op2( ) lopration Op3( ).
sd Exemple break
Op1( )
Op2( )
break [F1]
annulerOp1( )
annulerOp2( )
afficherAide( )
Op3( )
Figure 3.48 Exemple de fragment dinteraction avec loprateur break
Oprateurs ignore et consider

Les oprateurs ignore et consider sont utiliss pour des fragments dinteractions dans
lesquels on veut montrer que certains messages peuvent tre soit absents sans avoir
dincidence sur le droulement des interactions (ignore), soit obligatoirement
prsents (consider).
Lexemple prsent figure 3.49 montre que :
dans le fragment consider, les messages Op1, Op2 et Op5 doivent tre obliga-
toirement prsents lors de lexcution du fragment sinon le fragment nest pas
excut,
dans le fragment ignore, les messages Op2 et Op3 peuvent tre absents lors de
lexcution du fragment.
Oprateur critical
Loprateur critical permet dindiquer quune squence dinteractions ne peut tre
interrompue compte tenu du caractre critique des oprations traites. On considre
que le traitement des interactions comprises dans la squence critique est atomique.
Lexemple prsent figure 3.50 montre que les oprations Op1( ), Op2( ) et Op3( )
du fragment critical doivent sexcuter sans interruption.
sd Exemple consider et ignore
: Classe1 : Classe2 : Classe3 : Classe4
consider {Op1,Op2,Op5)
Op1( ) Op2( )
Op3( )
Op5( )
ignore {Op2,Op3}
Op2( )
Op3( )
Op5( )
Figure 3.49 Exemple de fragment dinteraction

avec les oprateurs ignore et consider
sd Exemple oprateur critical
critical
Op1( )
Op2( )
Op3( )
Figure 3.50 Exemple de fragment dinteraction avec loprateur critical

Oprateur negative
Loprateur neg (negative) permet dindiquer quune squence dinteractions est
invalide.
Lexemple prsent figure 3.51 montre que les oprations Op1( ) et Op2( ) du frag-
ment neg sont invalides. Une erreur sera dclenche dans ce cas lexcution du
fragment.
sd Exemple oprateur negative
neg
Op1( )
Op2( )
Figure 3.51 Exemple de fragment dinteraction avec loprateur neg
Oprateur assertion
Loprateur assert (assertion) permet dindiquer quune squence dinteractions est
lunique squence possible en considrant les messages changs dans le fragment.
Toute autre configuration de message est invalide.
Lexemple prsent figure 3.52 montre que le fragment assert ne sexcutera que si
lunique squence de traitement Op1( ), Op2( ) et Op3( ) se ralise en respectant
lensemble des caractristiques de ces oprations (paramtre dentre, type de
rsultat). Toute autre situation sera considre invalide.
Oprateur ref
Loprateur ref permet dappeler une squence dinteractions dcrite par ailleurs
constituant ainsi une sorte de sous-diagramme de squence.
Lexemple prsent figure. 3.53 montre que lon fait appel un fragment Contrle
des droits qui est dcrit par ailleurs.
sd Exemple oprateur assert
assert
Op1( )
Op2( )
Op3( )
Figure 3.52 Exemple de fragment dinteraction avec loprateur assert
sd Gestion des contrats

: Gestionnaire
saisieIdcontrat( ) contrlerdroitContrat( )
ref
Contrle des droits
Figure 3.53 Exemple de fragment dinteraction avec loprateur ref
3.4.4 Autre utilisation du diagramme de squence

Le diagramme de squence peut tre aussi utilis pour documenter un cas dutilisa-
tion. Les interactions entre objets reprsentent, dans ce cas, des flux dinformations
changs et non pas de vritables messages entre les oprations des objets. Un
exemple de cette utilisation du diagramme de squence est donn la figure 3.54.
Scnario A
Client X
Reprsentant Commande Facture
Demande
Disponibilit
articles
Rponse
Proposition disponibilit
commande
Commande
Commande
Facturation
Facture
Figure 3.54 Exemple de diagramme de squence associ un cas dutilisation
3.4.5 Exercices
Exercice 1
En se rfrant au sujet de lexercice 3 du diagramme de classe, nous donnons titre
dexemple, la figure 3.55 le diagramme de squence. Ce scnario correspond la
cration dune agence intgrant la cration dune personne.
: DirectionRgionale
1 : Cration
d'une agence
agence : Agence
2 : Cration
du directeur de lagence
personnel : Personnel
3 : Directeur
de lagence cr
4 : Agence cre
Figure 3.55 Exemple de diagramme de squence de lexercice 1

Exercice de synthse
Nous reprenons ici les cas dutilisation dcrits dans lexercice de synthse du DCU.
La figure 3.56 reprsente le DSE du cas dutilisation Gestion annuelle du catalogue.
La figure 3.57 reprsente le DSE du cas dutilisation Publication du catalogue.
<<boundary>> Propritaire Activit

IHM Gte Catalogue
: Gestionnaire catalogue
crationGte( )
opt Cration propritaire

si propritaire
crationPropritaire( ) <<create>> nexiste pas
crationPropritaire( )
contrleSaisie( )
opt Traitement erreur saisie
crationPropritaire( )
<<create>>
crationGte( )
contrleSaisie( )
opt Erreur saisie gte
MAJactivit( )
ajoutGte( )
contrlerGte( )
opt Erreur saisie gte
contrlePropritaire( )
alt Traitement gte

)
[Contrle OK]
modifActivit( )
[Contrle non OK]
erreur propritaire
Figure 3.56 Diagramme de squence de la Gestion du catalogue

de lexercice de synthse
<<boundary>> Catalogue Gte Propritaire Priode Activit

IHM location
: Gestionnaire catalogue propritaire

demandelaborationCatalogue( ) loop Traitement gte
afficheCatalogue( ) affichePropritaire( ) pour tous les gtes
afficheGte( )
afficheTarifSemaine( )
afficheActivit( )
Figure 3.57 Exemple de diagramme de squence de lexemple rcapitulatif
3.5 DIAGRAMME DE COMMUNICATION (DCO)

Le diagramme de communication constitue une autre reprsentation des interac-
tions que celle du diagramme de squence. En effet, le diagramme de communica-
tion met plus laccent sur laspect spatial des changes que laspect temporel.
Rle
Chaque participant un change de message correspondant une ligne de vie dans
le diagramme de squence se reprsente sous forme dun rle dans le diagramme de
communication. Un rle est identifi par :
<nom de rle> : <nom du type>
Une des deux parties de cette identification est obligatoire ainsi que le sparateur
: . Le nom du rle correspond au nom de lobjet dans le cas o lacteur ou la classe
ont un rle unique par rapport au systme. Le nom du type correspond au nom de la
classe lorsque lon manipule des objets.
Exemple
administrateur : utilisateur
Pour un utilisateur qui est vu au travers de son rle dadministrateur.
Message
Un message correspond un appel dopration effectu par un rle metteur vers un
rle rcepteur. Le sens du message est donn par une flche porte au-dessus du lien
3.5 Diagramme de communication (DCO) 105
reliant les participants au message (origine et destinataire). Chaque message est

identifi par :
<numro> : nom ( )
Plus prcisment lidentification dun message doit respecter la syntaxe suivante :
[n du message prc. reu] . n du message [clause ditration] [condition]
: nom du message.
Numro du message prcdent reu : permet dindiquer la chronologie des
messages.
Numro du message : numro hirarchique du message de type 1.1, 1.2 avec
utilisation de lettre pour indiquer la simultanit denvoi de message.
Clause ditration : indique si lenvoi du message est rpt. La syntaxe est *
[spcification de litration].
Condition : indique si lenvoi du message est soumis une condition satis-
faire.
Exemples
1.2.1 * [3 fois] pour un message adresser trois fois de suite.
1.2a et 1.2b pour deux messages envoys en mme temps.
Exemple rcapitulatif de dsignation de message :
1.2a.1.1[si t > 100] : lancer( )
Ce message signifie :
1.2a : numro du message reu avant lenvoi du message courant.
1.1 : numro de message courant envoyer.
[si t > 100] : message envoyer si t > 100.
lancer( ) : nom du message envoyer.
3.5.2 Formalisme et exemple

Les rles correspondent des objets. Le lien entre les rles est reprsent par un trait
matrialisant le support des messages changs. La figure 3.58 donne le formalisme
de base du diagramme de communication.
objet 1 : classe 1 objet 2 : classe 2
Sens et identification du message
Figure 3.58 Formalisme de base du diagramme de communication

Un exemple de diagramme de communication est donn la figure 3.59.
sd Communication
1- commandeDemande( )
Client Commande
2- rechercheProduit( )
3- commandeRalise( )
Produit
Figure 3.59 Exemple de diagramme de communication
3.5.3 Exercices
Exercice 1
En reprenant le sujet de lexercice 1 du diagramme de squence, nous donnons la
figure 3.60 son quivalent en diagramme de communication.
1: Cration dune agence
: Direction rgionale agence :unit

Agence
4 : Agence cre
3 : Cration dun personnel ralise 2 : Cration dun personnel de lagence
personnel : Personnel
Figure 3.60 Exemple densemble du diagramme de collaboration
3.6 DIAGRAMME GLOBAL DINTERACTION (DGI)

Le diagramme global dinteraction permet de reprsenter une vue gnrale des inte-
ractions dcrites dans le diagramme de squence et des flots de contrle dcrits dans
le diagramme dactivit.
3.6 Diagramme global dinteraction (DGI) 107
Le diagramme global dinteraction privilgie la vue gnrale des flux de contrle

dans lesquels les nuds sont des interactions ou des utilisations dinteractions (op-
rateur ref).
Autrement dit, le diagramme global dinteraction est un diagramme dactivit
dans lequel on reprsente des fragments dinteraction ou des utilisations dinterac-
tions. Ainsi, il est possible de reprsenter :
des choix de fragments dinteractions (fusion) ;
des droulements parallles de fragments dinteractions (dbranchement et
jonction) ;
des boucles de fragments dinteraction.
Les lignes de vie concernes par le diagramme global dinteraction peuvent tre
cites dans len-tte du diagramme mais ne sont pas reprsenter graphiquement.
Concepts manipuls
Le diagramme global dinteraction utilise les concepts du diagramme dactivit
auquel on ajoute deux complments :
Les fragments dinteraction du diagramme de squence Il sagit comme le
montre la figure 3.61 de la notion de fragment dinteraction vue dans le
diagramme de squence mais qui ne doit pas tre dtaill ce niveau.
sd Interaction
Client Commande
commander( )
Figure 3.61 Exemple de fragment dinteraction
Les utilisations de fragments dinteraction Il est aussi possible de faire

appel des fragments dinteraction laide de loprateur ref comme le montre
la figure 3.62.
ref
Nom du fragment
Figure 3.62 Exemple de fragment dinteraction avec loprateur ref

3.6.2 Reprsentation et exemple

La figure 3.63 donne un exemple de diagramme global dinteraction.
sd Diagramme global lignes de vie : Utilisateur, systmeContrle
ref
activer systmeContrle Accs
sd
Utilisateur systmeContrle
contrlerCode
Contrle non OK
Contrle OK
sd
Utilisateur systmeContrle
Message Entrer
ref
ouvrirPorte
Figure 3.63 Exemple de diagramme global dinteraction

3.7 Diagramme de temps (DTP) 109
3.7 DIAGRAMME DE TEMPS (DTP)

Le diagramme de temps permet de reprsenter les tats et les interactions dobjets dans
un contexte o le temps a une forte influence sur le comportement du systme grer.
Autrement dit, le diagramme de temps permet de mieux reprsenter des change-
ments dtats et des interactions entre objets lis des contraintes de temps.
Pour cela, le diagramme de temps utilise en plus des lignes de vie, les concepts
suivants :
Des tats ou des lignes de temps conditionnes avec deux reprsentations
graphiques possibles.
Des reprsentations propres aux aspects temporels : chelle de temps,
contrainte de dure, vnements
Concepts manipuls
Le diagramme de temps utilise trois concepts de base :
Ligne de vie Elle reprsente lobjet que lon veut dcrire. Elle se dessine de
manire horizontale. Plusieurs lignes de vie peuvent figurer dans un
diagramme de temps.
tat ou ligne de temps conditionne Les diffrents tats que peut prendre
lobjet dtude sont lists en colonne permettant ainsi de suivre le comporte-
ment de lobjet ligne par ligne (une ligne pour un tat).
tats linaires Il sagit du mme concept que le prcdent, mais la reprsen-
tation de la succession des tats est faite de manire linaire laide dun
graphisme particulier.

Soit reprsenter le dispositif de chauffe dun fer repasser vapeur au moment de
sa mise en service selon les rgles suivantes :
la pompe eau qui remplit la chambre de chauffe sactive ds que le tmoin
deau interne le demande ;
la pompe eau se dsactive ds que le niveau deau ncessaire est atteint ;
le chauffage de leau, permettant de produire la vapeur, se met en action la
premire mise en service du fer repasser ds que le niveau deau de la cham-
bre de chauffe est suffisant ;
le chauffage initial de leau dure 3 mm permettant ainsi de produire la vapeur.
Dans cet exemple, nous avons deux objets tudier : pompe eau et chauffage de
leau. Nous allons considrer pour chacun dentre eux deux tats significatifs : activ
et dsactiv.
La figure 3.64 donne la reprsentation du diagramme de temps en utilisant le for-

malisme des tats en escalier et la figure 3.65 fournit la reprsentation linaire
des tats.
sd Chauffage vapeur
Vapeur demande
et rserve eau Rserve eau
:pompe eau
insuffisante suffisante
activ
dsactiv
:chauffage eau
activ
dsactiv { t..t +3}
timer t
Figure 3.64 Exemple de diagramme de temps

avec reprsentation en escalier
sd Chauffage vapeur
Vapeur demande Rserve eau

:pompe eau
et rserve eau suffisante

insuffisante
dsactiv activ dsactiv

:chauffage eau
dsactiv activ dsactiv
{ t..t +3}
timer t
Figure 3.65 Exemple de diagramme de temps avec reprsentation linaire

4
Dmarche
de dveloppement
Nous proposons dans ce chapitre tout dabord une synthse des deux principaux
processus de dveloppement objet qui ont t associs UML. Il sagit de UP
(Unified Process) et de RUP (Rational Unified Process). Ensuite nous prsentons notre
propre dmarche de dveloppement UP7 qui est fonde sur UP.
4.1 PRSENTATION DUP

UML nest quun langage de modlisation. Nous navons pas aujourdhui dans la
norme, de dmarche unifie pour construire les modles et conduire un projet
mettant en uvre UML. Cependant les auteurs dUML, ont dcrit, dans un ouvrage
[Jacobson2000a] le processus unifi (UP, Unified Process) qui doit tre associ
UML. Nous nallons pas, dans le cadre de cet ouvrage, donner une prsentation
dtaille dUP. Cependant il nous a paru intressant de dgager les ides fondatrices
dUP dans le cadre dune prsentation gnrale. Nous allons tout dabord expliciter
les principes de la mthode UP. Nous complterons ensuite cette prsentation gn-
rale en dcrivant larchitecture deux dimensions dUP et ses principaux concepts,
nous passerons aussi en revue les diffrentes phases dUP, et pour finir nous dtaille-
rons les activits dUP.
112 Chapitre 4. Dmarche de dveloppement
4.2 LES PRINCIPES DUP

Le processus de dveloppement UP, associ UML, met en uvre les principes
suivants :
processus guid par les cas dutilisation,
processus itratif et incrmental,
processus centr sur larchitecture,
processus orient par la rduction des risques.
Ces principes sont la base du processus unifi dcrit par les auteurs dUML.
4.2.1 Processus guid par les cas dutilisation

Lorientation forte donne ici par UP est de montrer que le systme construire se
dfinit dabord avec les utilisateurs. Les cas dutilisation permettent dexprimer les
interactions du systme avec les utilisateurs, donc de capturer les besoins.
Une seconde orientation est de montrer comment les cas dutilisation consti-
tuent un vecteur structurant pour le dveloppement et les tests du systme. Ainsi le
dveloppement peut se dcomposer par cas dutilisation et la rception du logiciel
sera elle aussi articule par cas dutilisation.
4.2.2 Processus itratif et incrmental

Ce type de dmarche tant relativement connu dans lapproche objet, il parat
naturel quUP prconise lutilisation du principe de dveloppement par itrations
successives. Concrtement, la ralisation de maquette et prototype constitue la
rponse pratique ce principe. Le dveloppement progressif, par incrment, est aussi
recommand en sappuyant sur la dcomposition du systme en cas dutilisation.
Les avantages du dveloppement itratif se caractrisent comme suit :
les risques sont valus et traits au fur et mesure des itrations,
les premires itrations permettent davoir un feed-back des utilisateurs,
les tests et lintgration se font de manire continue,
les avances sont values au fur et mesure de limplmentation.
4.2.3 Processus centr sur larchitecture

Les auteurs dUP mettent en avant la proccupation de larchitecture du systme
ds le dbut des travaux danalyse et de conception. Il est important de dfinir le plus
tt possible, mme grandes mailles, larchitecture type qui sera retenue pour le
dveloppement, limplmentation et ensuite le dploiement du systme. Le vecteur
des cas dutilisation peut aussi tre utilis pour la description de larchitecture.
4.3 Les concepts et les deux dimensions du processus UP 113
4.2.4 Processus orient par la rduction des risques

Lanalyse des risques doit tre prsente tous les stades de dveloppement dun
systme. Il est important de bien valuer les risques des dveloppements afin daider
la bonne prise de dcision. Du fait de lapplication du processus itratif, UP
contribue la diminution des risques au fur et mesure du droulement des itra-
tions successives.
4.3 LES CONCEPTS ET LES DEUX DIMENSIONS DU

PROCESSUS UP
4.3.1 Dfinition des principaux concepts et schma densemble

Le processus unifi dcrit qui fait quoi, comment et quand les travaux sont raliss
tout au long du cycle de vie du projet. Quatre concepts dUP rpondent ces
questions :
Rle (qui ?)
Activit (comment ?)
Artefact (quoi ?)
Workflow (quand ?)
Rle
Un rle dfinit le comportement et les responsabilits dune ressource ou dun
groupe de ressources travaillant en quipe. Le rle doit tre considr en termes de
casquette quune ressource peut revtir sur le projet. Une ressource peut jouer
plusieurs rles sur le projet.
Par exemple sur un projet, Paul peut tre la fois chef de projet et architecte. Il
reprsente deux rles au sens dUP (fig. 4.1).
Activit
Les rles ont des activits qui dfinissent le travail quils effectuent. Une activit est
une unit de travail quune ressource, dans un rle bien prcis, peut effectuer et qui
produit un rsultat dans le cadre du projet. Lactivit a un but clairement tabli,
gnralement exprime en termes de cration ou de mise jour dartefacts, comme
un modle, une classe ou un planning. Les ressources sont affectes aux activits
selon leurs comptences et leur disponibilit.
Par exemple, les activits planifier une itration et anticiper les risques
sont attribues au rle de chef de projet.
Le schma de la figure 4.1 prsente sur un exemple le positionnement et les liens
entre ressources, rles et activits.
Artefacts
Un artefact est un ensemble dinformations qui est produit, modifi ou utilis par le
processus. Les artefacts sont les produits effectifs du projet. Les artefacts sont utiliss
comme input par les ressources pour effectuer une activit et sont le rsultat doutput
dactivits du processus.
Un exemple dartefacts rencontrs au cours du projet est un planning dune itra-
tion ou un diagramme produit dans une activit.
Ressources Rles Activits
Paul Chef de projet

Anticiper les risques
Pierre
Architecte
Concevoir lapplication
Rdiger le dossier darchitecture
Figure 4.1 Schma de positionnement des ressources, rles et activits
Workflows
Une numration de tous les rles, activits et artefacts ne constitue pas un
processus. En effet, il est ncessaire davoir une faon de dcrire des squences dacti-
vits mesurables qui produisent un rsultat de qualit et montre linteraction entre
les ressources. Le workflow est une squence dactivits qui produit un rsultat
mesurable. En UML, il peut tre exprim par un diagramme de squence, un
diagramme de communication ou un diagramme dactivit.
Schma densemble
UP peut tre dcrit suivant deux dimensions traduites en deux axes comme le
montre la figure 4.2 :
Un axe horizontal reprsentant le temps et montrant laspect dynamique du
processus. Sur cet axe, le processus est organis en phases et itrations.
Un axe vertical reprsentant laspect statique du processus. Sur cet axe, le
processus est organis en activits et workflows.
4.3.2 Phases et itrations du processus (aspect dynamique)

Le processus unifi, organis en fonction du temps, est divis en quatre phases
successives.
Inception (Lancement).
laboration.
Construction.
Transition.
4.3 Les concepts et les deux dimensions du processus UP 115
Organisation en fonction du temps : les phases et itrations
Inception
Organisation
en fonction
du contenu :
les activits
Itrations
Figure 4.2 Schma densemble dUP
Inception (Lancement)
Cette phase correspond linitialisation du projet o lon mne une tude doppor-
tunit et de faisabilit du systme construire. Une valuation des risques est aussi
ralise ds cette phase.
En outre, une identification des principaux cas dutilisation accompagne dune
description gnrale est modlise dans un diagramme de cas dutilisation afin de
dfinir le primtre du projet. Il est possible, ce stade, de faire raliser des maquet-
tes sur un sous-ensemble des cas dutilisation identifis.
Ce nest qu lissue de cette premire phase que lon peut considrer le projet
vritablement lanc.
laboration
Cette phase reprend les rsultats de la phase dinception et largit lapprciation de
la faisabilit sur la quasi-totalit des cas dutilisation. Ces cas dutilisation se retrou-
vent dans le diagramme des cas dutilisation qui est ainsi complt.
Cette phase a aussi pour but danalyser le domaine technique du systme dve-
lopper afin daboutir une architecture stable. Ainsi, toutes les exigences non recen-
ses dans les cas dutilisation, comme par exemple les exigences de performances du
systme, seront prises en compte dans la conception et llaboration de larchitec-
ture.
Lvaluation des risques et ltude de la rentabilit du projet sont aussi prcises.
Un planning est ralis pour les phases suivantes du projet en indiquant le nombre
ditrations raliser pour les phases de construction.
Construction
Cette phase correspond la production dune premire version du produit. Elle est
donc fortement centre sur les activits de conception, dimplmentation et de test.
En effet, les composants et fonctionnalits non implments dans la phase prc-
dente le sont ici.
Au cours de cette phase, la gestion et le contrle des ressources ainsi que lopti-
misation des cots reprsentent les activits essentielles pour aboutir la ralisation
du produit. En parallle est rdig le manuel utilisateur de lapplication.
Transition
Aprs les oprations de test menes dans la phase prcdente, il sagit dans cette
phase de livrer le produit pour une exploitation relle. Cest ainsi que toutes les
actions lies au dploiement sont traites dans cette phase.
De plus, des bta tests sont effectus pour valider le nouveau systme auprs
des utilisateurs.
Itrations
Une phase peut-tre divise en itrations. Une itration est un circuit complet de dve-
loppement aboutissant une livraison (interne ou externe) dun produit excutable.
Ce produit est un sous-ensemble du produit final en cours de dveloppement, qui
crot incrmentalement ditration en itration pour devenir le systme final.
Chaque itration au sein dune phase aboutit une livraison excutable du systme.
4.3.3 Activits du processus (aspect statique)

Les activits menes lintrieur des quatre phases sont plus classiques, car dj bien
documentes dans les mthodes existantes par ailleurs. Nous nous limiterons donc
ne donner quune brve explication de chaque activit.
Expression des besoins

UP propose dapprhender lexpression des besoins en se fondant sur une bonne
comprhension du domaine concern pour le systme dvelopper et une modlisa-
tion des procdures du systme existant.
Ainsi, UP distingue deux types de besoins :
les besoins fonctionnels qui conduisent llaboration des cas dutilisation,
les besoins non fonctionnels (techniques) qui aboutissent la rdaction dune
matrice des exigences.
Analyse
Lanalyse permet une formalisation du systme dvelopper en rponse lexpres-
sion des besoins formule par les utilisateurs. Lanalyse se concrtise par llaboration
4.4 Les principaux apports de RUP 117
de tous les diagrammes donnant une reprsentation du systme tant statique

(diagramme de classe principalement), que dynamique (diagramme des cas dutilisa-
tion, de squence, dactivit, dtat-transition).
Conception
La conception prend en compte les choix darchitecture technique retenus pour le
dveloppement et lexploitation du systme. La conception permet dtendre la
reprsentation des diagrammes effectue au niveau de lanalyse en y intgrant les
aspects techniques plus proches des proccupations physiques.
Implmentation
Cette phase correspond la production du logiciel sous forme de composants, de
bibliothques ou de fichiers. Cette phase reste, comme dans toutes les autres mthodes,
la plus lourde en charge par rapport lensemble des autres phases (au moins 40 %).
Test
Les tests permettent de vrifier :
la bonne implmentation de toutes les exigences (fonctionnelles et techniques),
le fonctionnement correct des interactions entre les objets,
la bonne intgration de tous les composants dans le logiciel.
Classiquement, diffrents niveaux de tests sont raliss dans cette activit : test
unitaire, test dintgration, test de rception, test de performance et test de non-
rgression.
Aprs cette prsentation dUP et afin dclairer le lecteur sur les principaux pro-
cessus de dveloppement actuellement utiliss dans lapproche objet, nous donnons
ci-aprs une description gnrale de RUP.
En son temps, la socit Rational Software (rachete par IBM) avait dvelopp
une version spcifique dUP sous le nom de RUP (Rational Unified Process), cette
dmarche a fait lobjet dun ouvrage [Kruchten2000]. Dans la prsentation qui
suit, nous avons surtout mis laccent sur les principaux apports de RUP par rapport
UP.
4.4 LES PRINCIPAUX APPORTS DE RUP
RUP (Rational Unified Process) est un processus bas sur une approche discipline
afin de bien matriser lassignation des tches et la responsabilisation des diffrents
acteurs participant au cycle de dveloppement du logiciel. RUP a pour objectif prin-
cipal de faire appliquer les bonnes pratiques de dveloppement aux entreprises, ce
qui confre au produit final une meilleure qualit.
RUP se veut tre un modle volutif qui doit tre configur pour pouvoir tre uti-
lis en intgrant les contraintes, les spcificits et lhistorique de lorganisation qui
ladopte.
Nous allons prsenter les principaux apports de RUP par rapport UP en traitant
les points suivants :
les bonnes pratiques,
les phases du processus,
les activits du processus.
4.4.1 Les bonnes pratiques

RUP adhre six bonnes pratiques de dveloppement observes dans lindustrie
pour leurs succs. Sur ces six bonnes pratiques, trois sont issues des principes dUP :
Dveloppement itratif et incrmental.
Dveloppement pilot par les cas dutilisation.
Forte importance de larchitecture.
Trois autres bonnes pratiques ont t introduites par RUP :

Modlisation visuelle.
Vrification continue de la qualit.
Contrle des changements du logiciel.
Modlisation visuelle
RUP prconise lutilisation dun langage de modlisation standard comme UML qui
permet aux membres de lquipe de dveloppement de communiquer sans ambi-
gut.
Lutilisation doutils de modlisation visuelle est fortement recommande par
RUP. Ceux-ci permettent de modliser larchitecture et ses composants laide de
diagrammes. De plus, ils facilitent la gestion des modles de RUP et contribuent
maintenir la cohrence entre les diffrentes phases du processus : de lexpression des
besoins limplmentation. En rsum, la modlisation visuelle permet de grer la
complexit des logiciels.
Vrification continue de la qualit

RUP met laccent sur limportance dvaluer continuellement la qualit dun
systme du point de vue des fonctionnalits, de la fiabilit et de la performance. Pour
cela, RUP vous assiste dans la planification, la conception, limplmentation et
lexcution des tests adquats.
Ces tests sont raliss tout au long du processus, dans toutes les activits, en
impliquant tous les acteurs, et en utilisant des critres et des mesures objectifs (ex.
tests dintgration continus).
Contrle des changements du logiciel

RUP propose une coordination des activits et des livrables des quipes afin de grer
activement les changements du logiciel. Pour cela le processus organise les activits
en enchanement dactivits (workflows). Ces workflows dcrivent comment
contrler, suivre et mesurer les changements du logiciel. De plus, ils permettent une
meilleure allocation des ressources base sur les priorits et les risques du projet et
facilitent la gestion du travail sur ces changements au travers des itrations.
Combine au dveloppement itratif, cette technique permet de contrler les chan-
gements de sorte quil soit possible de dcouvrir rapidement les ventuels problmes
et dy ragir.
4.4.2 Les phases et les activits du processus

Comme UP, RUP est un processus deux dimensions. Il est modlis par un schma
articul suivant deux axes (fig. 4.3) :
Laxe horizontal reprsentant le temps et montrant les phases et les itrations
du processus,
Laxe vertical reprsentant laspect statique du processus. Les activits sont
reprsentes sur cet axe, RUP propose neuf activits (quatre de plus que le
processus UP).
1
2
3
4
5
6
8
9
Figure 4.3 Schma densemble de RUP
Les phases et les jalons

Les phases dans le processus RUP sont les mmes que celles du processus UP. Le
concept de jalon est introduit par RUP. Chaque phase est conclue par un jalon. Ce
jalon est constitu dun ensemble de critres dvaluation. Ces critres doivent tre
satisfaits pour passer la phase suivante. La figure 4.4 illustre les diffrents jalons au
cours du processus.
IOC
LCO LCA PR
Capacit
Objectifs Architecture Livraison
oprationnelle
du cycle de vie du cycle de vie du produit
initiale
Lancement laboration Construction Transition
temps
Figure 4.4 Les phases et jalons dans RUP
Le jalon LCO
La phase de lancement se termine par le jalon Objectifs du cycle de vie . Ce jalon
permet de sassurer que les critres suivants sont bien pris en compte par le projet :
Les exigences fondamentales, les caractristiques cls et les contraintes princi-
pales sont documentes.
tude de rentabilit dfinie et approuve.
Estimation de charge raliste, phases identifies, priorits dfinies et risques
dfinis.
Planning de phase dlaboration dfini.
Primtre dfini.
Le jalon LCA
La phase dlaboration se termine par le jalon Architecture du cycle de vie . Ce
jalon permet de sassurer que les critres suivants sont bien appliqus dans le projet :
Un ou plusieurs prototypes ont t raliss pour explorer les fonctionnalits
critiques et les scnarios architecturalement significatifs.
Architecture du projet dfinie et stable.
Risques dfinis et pris en compte dans larchitecture.
Planning des phases suivantes dtaill et prcis.
Le jalon IOC
La phase de construction se termine par le jalon Capacit oprationnelle
initiale . Ce jalon permet de sassurer que les critres suivants sont bien appliqus
dans le projet :
Version du produit assez stable et mature pour tre fournie au client.
Les tests sont tablis et dvelopps pour valider les versions excutables.
Les clients sont prts accueillir le produit.

Les risques sont matriss.
Le plan ditration pour la phase de transition est complt et vrifi.
Le jalon PR
La phase de transition se termine par le jalon Livraison du produit . Ce jalon
permet de sassurer que les critres suivants sont bien appliqus dans le projet :
Le produit complet et achev en accord avec les exigences du client est dploy.
Le client est satisfait.
Les dpenses du projet correspondent aux dpenses prvues.
Les activits
Les activits de RUP, dcrites ci-aprs, sont celles qui sont nouvelles par rapport
UP. Les autres activits sont dj dcrites dans UP.
Modlisation mtier
La modlisation mtier permet de mieux comprendre la structure et la dynamique
de lorganisation tudie. Elle assure au client que les utilisateurs finaux et les dve-
loppeurs partagent une vision commune de lorganisation. Elle permet daboutir
une cartographie des processus mtier de lorganisation cliente.
Gestion des exigences

La gestion des exigences a pour but de dfinir ce que doit faire le systme. Pour cela,
les cas dutilisation sont raliss. Ils permettent aussi de structurer les documents de
spcifications fonctionnelles. Les cas dutilisation sont en effet dcomposs en
scnarios dusage du systme dans lesquels lutilisateur dcrit ce quil fait grce au
systme et ses interactions avec le systme (description dtaille des cas dutilisa-
tion).
Les exigences non fonctionnelles (performances, qualits) peuvent aussi tre
dcrites dans un document complmentaire de spcification.
Dploiement
Le but de lenchanement des activits de dploiement est de livrer le produit aux
utilisateurs finaux. Cela inclut de nombreuses sous-activits :
Packaging du logiciel.
Livraison du logiciel.
Migration des donnes existantes (dans certains cas).
Installation du logiciel.
Assistance aux utilisateurs.
Ces sous-activits sont ralises pour la plupart lors de la phase de transition.
Nanmoins, un certain nombre dentre elles doivent tre prpares lors de la phase
de construction comme par exemple le packaging du logiciel.
Gestion de la configuration et du changement

Lobjectif de la gestion de la configuration et des changements est de garder la trace
de tous les lments tangibles qui participent au dveloppement et de suivre leur
volution.
Pour cela, il faut traiter les points suivants :
Identifier les lments en configuration du projet.
Contrler les modifications de ces lments via un outil de gestion de configu-
ration.
Grer les configurations de ces lments au cours du processus de dveloppe-
ment du logiciel laide despaces de travail (espace de dveloppement,
espace dintgration et espace de livraison).
Grer les changements des lments en configuration du projet laide de
demandes de changement. Celles-ci sont utilises pour documenter et tracer
les anomalies, les demandes dvolution et tout type de requte entranant
une modification du produit. Elles assurent que les impacts des modifications
sont pris en compte tous les niveaux.
Auditer la mise en place de lactivit de gestion de configuration et du chan-
gement.
La gestion de configuration est ralise tout au long du projet. La gestion du chan-

gement sapplique principalement dans les phases de construction et de transition.
Gestion de projet
La gestion dun projet logiciel est lart de mesurer les objectifs comptitifs, de grer
les risques et les contraintes pour fournir un produit qui satisfait les besoins exprims
par les utilisateurs.
Pour cela, RUP insiste sur laspect itratif du processus de dveloppement et four-
nit un cadre de travail dj document par :
un framework pour la gestion dun projet logiciel,
des conseils pour la planification, lallocation des ressources, la prise de dci-
sion et le suivi de projet,
un framework pour grer les risques.
Cette approche permet daugmenter les chances de succs du projet.
Environnement
La gestion de lenvironnement consiste mettre en place tout ce qui permet aux
diffrents acteurs/rles de raliser au mieux leurs activits. Ce qui revient fournir
lorganisation, lenvironnement de dveloppement tant processus quoutils qui
va aider lquipe de dveloppement.
Cet environnement peut tre adapt pour chaque projet. Ainsi RUP fournit des
modles et des outils facilement adaptables aux diffrents types de projet.
4.5 Dmarche de dveloppement UP7 123
4.5 DMARCHE DE DVELOPPEMENT UP7
4.5.1 Prsentation gnrale

Schma densemble
Nous proposons ici une dmarche dapplication dUML qui prend appui sur UP mais
qui se veut avant tout tre pragmatique. Cette dmarche est fonde dune part sur
notre vision du processus de dveloppement et dautre part sur notre propre exp-
rience tire de la ralisation en entreprise de projets avec UML.
La dmarche que nous proposons est articule suivant deux axes : les quatre pha-
ses qui correspondent celles dUP et sept activits. Ainsi, on peut prsenter ds ce
stade un premier schma densemble de la dmarche suivant ces deux axes (fig. 4.5).
PHASES Lancement laboration Construction Transition

ACTIVITS
1- Modlisation mtier
2- Exigences
fonctionnelles
3- Analyse
des cas dutilisation
4- Synthse
de lanalyse
5- Conception
6- Implmentation
7- Test
Figure 4.5 Schma densemble de la dmarche UP7
Le gris sur le schma reprsente leffort consentir pour chaque activit durant
les phases dun projet. Ainsi par exemple, pour lactivit 3 (Analyse des cas dutilisa-
tion), lactivit commence lgrement lors de la phase de lancement puis se droule
principalement lors de la phase dlaboration et se termine en phase de construction.
Il est noter que sur le schma, la proportion que reprsente chaque activit par
rapport lensemble de la charge de dveloppement dun projet a t respecte gra-
phiquement.
Compte tenu de notre exprience et des ratios habituellement constats dans la
profession, nous avons retenu la rpartition indicative suivante pour les volumes
deffort consentir sur les activits dun projet.
Modlisation mtier : 5 %.
Exigences fonctionnelles : 5 %.
Analyse des cas dutilisation : 20 %.
Synthse de lanalyse : 5 %.
Conception : 10 %.
Implmentation : 40 %.
Test : 15 %.
Il importe bien entendu, de tenir compte pour chaque projet de ses spcificits en
termes par exemple de complexit fonctionnelle, contraintes techniques, et comp-
tence des ressources affectes.
Les activits 6 et 7, Implmentation et Tests , sont prsentes sur notre
schma pour couvrir ce niveau la totalit des activits en rfrence UP, mais elles
ne sont pas traites dans louvrage.
Cette dmarche est par dfinition itrative. Il est ainsi possible, si ncessaire, de
traiter des itrations lintrieur de chaque phase. Chaque itration doit se con-
clure par un produit livrable sous forme de maquette ou de prototype.
Des itrations successives permettent daffiner les rsultats de chaque phase.
Activit 1 Modlisation mtier

La premire activit de la dmarche consiste mieux connatre et comprendre les
processus dans lesquels va sintgrer le futur systme informatique. Cette activit
aboutit trois rsultats :
Au positionnement du systme tudier au sein de lensemble des processus
de lentreprise et la dfinition du primtre fonctionnel global du systme
(schma de contexte du domaine dtude).
la dfinition des processus mtiers concerns par le systme dvelopper et
lidentification des acteurs (diagramme dactivit).
la dfinition des concepts mtiers du domaine sous forme de classe
(diagramme de classe mtier). Les concepts mtiers correspondent aux infor-
mations cres, transformes ou manipules par les experts du domaine.
Lexpert du domaine y retrouve le vocabulaire de son mtier.
lissue de cette activit, le primtre du systme tudier est dfini.

Activit 2 Exigences fonctionnelles

La deuxime activit de la dmarche a pour but de dfinir ce que doit faire le systme
dun point de vue mtier. Cette activit permet dobtenir trois rsultats :
La dfinition des cas dutilisation mtier et leur description gnrale
(diagramme de cas dutilisation systme).
Les scnarios des cas dutilisation mtier (diagramme de squence systme).
La navigation gnrale du systme tudier, cest--dire linterface homme-
machine (schma de navigation gnrale).
Au terme de ces deux premires activits, lexpression des besoins (au sens UP)
est couverte.
Activit 3 Analyse des cas dutilisation

La troisime activit de la dmarche a pour but de fournir une vue informatique du
systme. Cette activit permet dobtenir cinq rsultats :
La dfinition de tous les cas dutilisation (mtiers + informatiques) et leur
description dtaille (diagramme des cas dutilisation).
Lidentification des scnarios pour chaque cas dutilisation (diagramme de
squence).
Les diffrents tats des objets tudis (diagramme dtat-transition). Cette
partie de lactivit est optionnelle et sapplique selon les systmes tudis.
Les interfaces utilisateur pour chaque cas dutilisation.
Les classes pour chaque cas dutilisation (diagramme de classe).
lissue de cette activit, lanalyse des cas dutilisation est produite mais non
encore consolide ni valide dfinitivement.
Activit 4 Synthse de lanalyse

La quatrime activit de la dmarche consiste consolider et valider toute lanalyse
des cas dutilisation. Cette activit permet dobtenir deux rsultats :
Le regroupement de lensemble des classes en un seul diagramme (diagramme
de classe rcapitulatif).
La validation de lanalyse de chaque cas par le biais dune matrice de valida-
tion. Celle-ci permet de vrifier que lanalyse des cas est complte, cest--dire
que tous les cas dutilisation mtier ont t repris dans lanalyse.
Au terme des activits 3 et 4, lanalyse (au sens activit UP) est couverte.
Activit 5 Conception
La cinquime activit de la dmarche se concentre sur le comment faire . Elle a
pour but de dfinir et de mettre en place les choix darchitecture technique, et de
complter la description du systme sous langle technique. Cette activit permet
dobtenir quatre rsultats :
Les choix techniques retenus.
Les scnarios techniques par cas dutilisation (diagrammes de squence tech-
nique).
Les classes techniques par cas dutilisation (diagrammes de classe technique).
Le regroupement sous forme de paquetage de lensemble des classes techni-
ques en un seul diagramme (diagramme de paquetage).
De ce fait la conception prliminaire est couverte par cette activit. La concep-

tion dtaille qui est la traduction des scnarios et classes techniques dans les solu-
tions technologiques retenues nest pas traite dans cet ouvrage.
Cette activit couvre la conception (au sens UP).
Les activits 6 et 7, Implmentation et Tests se rfrent aux activits

dUP, mais ne sont pas traites dans louvrage.
Schma de la dmarche
Pour illustrer la description gnrale des activits de la dmarche, la figure 4.6
prsente chaque activit avec ses diffrentes sous-activits. Une sous-activit
aboutit llaboration dun ou plusieurs diagrammes UML ou dun schma de
support au dveloppement du systme (hors UML). chaque sous-activit est asso-
cie une fiche guide qui est ensuite dtaille.
1 Modlisation mtier
1.1 laboration du schma de contexte du domaine dtude (FG1)

1.2 laboration du diagramme dactivit (FG2)
1.3 laboration du diagramme de classe mtier (FG3)
2 Exigences fonctionnelles
2.1 laboration du diagramme des cas dutilisation systme (FG4)

2.2 laboration des diagrammes de squence systme (FG5)
2.3 laboration du schma de navigation gnrale (FG6)
3 Analyse des cas dutilisation
3.1 laboration du diagramme des cas dutilisation (FG7)

3.2 Description des cas dutilisation (FG8)
3.3 laboration des diagrammes de squence (FG9)
3.4 laboration des diagrammes dtat-transition (FG10)
3.5 laboration des interfaces utilisateur (FG11)
3.6 laboration des diagrammes de classe (FG12)
4 Synthse de lanalyse
4.1 laboration du diagramme de classe rcapitulatif (FG13)

4.2 laboration de la matrice de validation (FG14)
5 Conception
5.1 Ralisation des choix techniques (FG15)

5.2 laboration des diagrammes de squence technique (FG16)
5.3 laboration des diagrammes de classe technique (FG17)
5.4 laboration du diagramme de paquetage (FG18)
6 Implmentation
Activit non traite dans cet ouvrage
7 Tests
Activit non traite dans cet ouvrage
Figure 4.6 Schma dtaill de la dmarche

4.5.2 Description des activits (fiche guide par sous-activit)

Nous proposons au lecteur une description de la dmarche laide de fiches guides
(FG). Un plan standard a t adopt pour la prsentation de ces fiches. Ce plan
traite : lobjectif, le point de dpart, le point darrive, la dmarche dlaboration et
les recommandations.
Ces fiches peuvent tre reprises et adaptes pour chaque projet compte tenu de
son contexte et de ses particularits.
Modlisation mtier
FICHE GUIDE FG1
Activit 1 : Modlisation mtier Projet :
Sous-activit 1.1 :
laboration du schma de contexte du domaine dtude Date :
Objectif Positionner le systme tudier au sein des processus de lentreprise.
Point de dpart Esquisse fonctionnelle du besoin exprim.
Point darrive Systme tudier positionn par rapport aux processus de lentreprise et
primtre fonctionnel dfini.
Dmarche dlaboration
1 Identifier les processus connexes au systme tudi.
2 Dterminer les interactions entre les processus connexes et le systme tudi.
3 Prciser le primtre du systme tudier (dfinition des sous-ensembles fonctionnels).
Recommandation :
Mettre en vidence le sous-ensemble tudier (sous-ensemble gris/mis en pointill) dans le
schma de contexte.
FICHE GUIDE FG2
Sous-activit 1.2 :
laboration du diagramme dactivit Date :
Objectif Dcrire les processus mtiers du systme tudier.
Point de dpart Systme tudier positionn par rapport aux processus de lentreprise et
primtre fonctionnel dfini.
Point darrive Acteurs identifis et processus mtiers du systme tudi dfinis (flot de
contrle, flot de donnes) dans le DAC.
Dmarche dlaboration
1 Identifier les acteurs internes et externes du systme tudi.
2 Identifier des actions du processus.
3 Dfinir le flot de contrle (enchanement des actions ) :

transitions automatiques,
transitions gardes,
synchronisation,
dbut/fin du flot.
4 Reprsenter les donnes lies aux actions. Ces donnes sont dcrites laide des concepts
du domaine. Ces concepts permettent dinitialiser le diagramme de classe mtier.
5 Dterminer le flot de donnes c'est--dire lenchanement des donnes entre elles et/ou avec
des actions.
6 Dcrire les rles des acteurs du systme.
Recommandations :
Veiller la lisibilit du DAC :
Limiter le nombre dactivits-actions reprsentes soit en privilgiant celles qui sont
structurantes, soit en utilisant une prsentation plusieurs niveaux.
Essayer dans la mesure du possible de tracer des flots faciles lire (viter les traits obliques).
FICHE GUIDE FG3
Sous-activit 1.3 :
laboration du diagramme de classe mtier Date :
Objectif Dfinir les concepts mtiers du domaine sous forme de classe.
Point de dpart Acteurs identifis et processus mtiers du systme tudi dfinis (flot de
contrle, flot de donnes).
Point darrive Concepts mtiers identifis dfinis dans le DCL mtier et le glossaire
mtier.
Dmarche dlaboration
1 Identifier les concepts du domaine sous forme de classes en prenant comme base ceux
dfinis dans le diagramme dactivit.
2 Prciser les principaux attributs utiles la comprhension des experts mtiers.
3 Dterminer les relations entre les classes :

nom de lassociation,
multiplicit.
4 Dcrire de manire gnrale les concepts du domaine afin dobtenir un glossaire mtier.
Recommandations :
1 Se limiter ce niveau aux concepts structurants pour le systme tudier.
2 laborer en synthse un dossier de modlisation mtier.
Exigences fonctionnelles
FICHE GUIDE FG4
Activit 2 : Exigences fonctionnelles Projet :
Sous-activit 2.1 :
laboration du diagramme des cas dutilisation systme Date :
Objectif Recueillir et dcrire les besoins mtiers des acteurs du systme

(bote noire).
Point de dpart Concepts mtiers identifis et dfinis dans le DCL mtier et le glossaire
mtier.
Point darrive Besoins mtiers recueillis sous la forme de cas dutilisation (DCU systme)
et dcrits de manire gnrale.
DMARCHE DLABORATION
1 Identifier les acteurs mtiers* du systme (acteurs internes et acteurs et/ou systmes
externes) en prenant comme base ceux dfinis dans le DAC.
2 Identifier les cas dutilisation mtiers**.
3 Reprsenter les interactions entre les acteurs mtiers et les cas dutilisation mtiers.
4 Dfinir les dpendances entre les cas dutilisation mtiers.
5 Dcrire de manire gnrale les cas dutilisation mtiers.
(*) Les acteurs mtiers identifis lors de cette tape sont ceux correspondant une vue mtier
du systme.
(**) Les cas dutilisation identifis lors de cette tape sont ceux correspondant une vue mtier
du systme.
Recommandations :
1 Utiliser des verbes pour dcrire les cas dutilisation.
2 Il est bon de se limiter moins dune dizaine de cas dutilisation ce niveau l.
FICHE GUIDE FG5
Sous-activit 2.2 :
laboration des diagrammes de squence systme Date :
Objectif Dfinir les interactions entre les acteurs mtiers et le systme (bote noire)
pour tous les cas dutilisation mtiers.
Point de dpart Besoins mtiers recueillis sous la forme de cas dutilisation et dcrits de
manire gnrale.
Point darrive Interactions entre acteurs mtiers et systme dfinis dans le DSE.
Dmarche dlaboration
Pour chaque cas dutilisation (CU) :
1 Reporter le ou les acteurs du CU slectionn sur le diagramme de squence systme (DSE).
2 Reprsenter le systme sous forme dobjet.
3 Dterminer les messages changs entre les acteurs et le systme (synchrones, asynchrones,
rsultats).
4 Reprsenter les fragments dinteraction combins si ncessaire (loop, alt, opt).
Recommandation :
Ne pas chercher, dans cette activit, dcrire le dtail des interactions entre les objets du
systme.
FICHE GUIDE FG6
Sous-activit 2.3 :
laboration du schma de navigation gnrale Date :
Objectif Dterminer la cinmatique des crans du systme.
Point de dpart Interactions entre acteurs et systme dfinies pour les cas dutilisation
mtiers.
Point darrive Linterface homme-machine gnrale dfinie.
Dmarche dlaboration
1 Identifier les principaux crans provenant des cas dutilisation mtiers et des interactions
dcrites dans le DSE systme. Les crans correspondent aux tats du schma de navigation
gnrale si lon utilise un diagramme dtat-transition pour la reprsentation de la navigation.
2 Prciser les vnements/conditions associs la transition entre les crans.
3 Indiquer ltat dbut/fin si ncessaire.
Recommandation :
Se limiter une premire vue gnrale de lenchanement des crans correspondant la
vision mtier.
Analyse des cas dutilisation
FICHE GUIDE FG7
Activit 3 : Analyse des cas dutilisation Projet :
Sous-activit 3.1 :
laboration du diagramme des cas dutilisation Date :
Objectif Dfinir la totalit des cas dutilisation (mtiers et informatiques). Les cas
dutilisation informatiques sont des fonctions complmentaires qui nont
pas t identifies lors de lactivit prcdente (ex. un module
dadministration).
Point de dpart Besoins mtiers, interactions acteurs mtiers/systme, IHM dfinies.
Point darrive Tous les cas dutilisation dfinis dans le DCU.
Dmarche dlaboration
1 Identifier tous les acteurs du systme en prenant comme base ceux dfinis dans le DCU
systme de lactivit prcdente. Les acteurs informatiques apparaissent ce niveau de
lanalyse (ex. Administrateur dune application).
2 Identifier tous les cas dutilisation en prenant comme base ceux dfinis dans le DCU systme
de lactivit prcdente. Ceux-ci sont souvent dcomposs un niveau plus dtaill. Les cas
dutilisation informatiques apparaissent ce niveau de lanalyse.
3 Reprsenter les interactions entre les acteurs et les cas dutilisation.
4 Dfinir les dpendances entre les cas dutilisations.
Recommandation :
Veiller limiter le nombre de cas dutilisation. Ne pas dpasser la dizaine par niveau de
description.
FICHE GUIDE FG8
Sous-activit 3.2 :
Description des cas dutilisation Date :
Objectif Dcrire de manire textuelle et dtaille les cas dutilisation.
Point de dpart Tous les cas dutilisation dfinis.
Point darrive Cas dutilisation dcrits de manire textuelle.
Dmarche dlaboration
1 Identifier lobjectif du CU.
2 Identifier les acteurs du CU partir du DCU de la sous-activit prcdente.
3 Dfinir les pr conditions et ventuellement post conditions du CU.
4 Dcrire le scnario nominal sous forme de liste dactions avec une numrotation
chronologique (1- Action 1, 2- Action 2). Lobjectif du CU doit tre atteint au terme du
scnario.
5 Dcrire le(s) scnario(s) alternatif(s) sous forme de liste dactions avec une numrotation
chronologique le reliant au scnario nominal (1a : titre 1, Cas alternatif a de ltape 1 du
scnario nominal). Le(s) scnario(s) alternatif(s) doit sachever par la satisfaction ou labandon
de lobjectif.
Recommandations :
1 Pour le scnario nominal :
Utiliser 3 9 actions.
viter de faire apparatre les dtails de lIHM dans les actions.
Utiliser des phrases courtes et simples pour les actions.
Ne pas utiliser les si sinon dans les actions.
2 Pour le scnario alternatif :
Terminer celui-ci par une action de ce type : le CU se termine ou le le CU reprend
au point N .
FICHE GUIDE FG9
Sous-activit 3.3 :
laboration des diagrammes de squence Date :
Objectif Reprsenter les interactions entre les acteurs et les objets du systme pour
tous les cas dutilisation en considrant les diffrents scnarios dcrits.
Point de dpart Cas dutilisation dcrits de manire textuelle et concepts mtiers identifis
et dfinis.
Point darrive Interactions entre acteurs et objets du systme dcrits dans le DSE pour
tous les cas dutilisation.
Dmarche dlaboration
Pour chaque cas dutilisation (CU) et chaque scnario identifi :
1 Reporter le ou les acteurs du DCU impliqus dans le scnario.
2 Reprsenter les objets du systme impliqus dans le scnario en prenant comme base ceux
identifis lors de lactivit de modlisation mtier.
3 Identifier les messages (synchrones/asynchrones) entre les acteurs et les objets et entre les
objets eux-mmes. La chronologie des changes doit tre respecte.
4 Modliser les fragments dinteractions si ncessaire.
Recommandations :
1 Se limiter la reprsentation des principaux scnarios de chaque CU.
2 Pour des messages ou des fragments dinteractions complexes, les expliciter par des notes.
3 Utiliser des fragments dinteraction de type ref pour faciliter la lecture du DSE.
FICHE GUIDE FG10
Sous-activit 3.4 :
laboration des diagrammes dtat-transition Date :
Objectif Dfinir dune part les tats des objets significatifs du systme tudi et
dautre part les actions associes aux transitions.
Point de dpart Cas dutilisation dcrits de manire textuelle et concepts mtiers identifis
et dfinis.
Point darrive Les diffrents tats des objets et les transitions entre objets reprsents
dans le DET.
Dmarche dlaboration
Pour chaque objet significatif du systme tudi :
1 Identifier les tats pertinents de lobjet reprsenter. Considrer les tats lmentaires mais
aussi composites si ncessaire.
2 Dfinir les transitions entre les tats des objets avec ventuellement les gardes associes.
Utiliser, le cas chant, tous les oprateurs disponibles (points de jonction, points de choix).
3 Dfinir les actions pour les transitions et les activits pour les objets.
4 Reprsenter ltat initial et le ou les tats finaux.
Recommandation :
Utiliser uniquement les diagrammes dtat pour des objets dont il est ncessaire de
comprendre le comportement dans tout le systme (tats caractrisques).
FICHE GUIDE FG11
Sous-activit 3.5 :
laboration des interfaces utilisateur Date :
Objectif Modliser les interfaces utilisateur de tous les cas dutilisation pour donner
une vue concrte de lapplication aux utilisateurs.
Point de dpart Cas dutilisation dcrits de manire textuelle et interactions entre acteurs et
objets du systme dfinies pour tous les cas dutilisation.
Point darrive Interfaces utilisateur dfinies pour tous les cas dutilisation.
Dmarche dlaboration
1 Identifier toutes les entres de lIHM qui correspondent aux paramtres des messages du
DSE pour chaque CU.
2 Reprsenter les dispositifs d entres sous forme de composants IHM :

zone de saisie lcran,
liste de choix,
boutons radios
3 Ajouter lIHM, les composants de validation (boutons).
4 Reprsenter les sorties de lIHM qui correspondent aux rsultats du message du DSE
pour chaque CU.
Recommandation :
Raliser des interfaces utilisateur simples facilement modifiables compte tenu des frquents
retours des utilisateurs traiter.
FICHE GUIDE FG12
Sous-activit 3.6 :
laboration des diagrammes de classe Date :
Objectif Dfinir les classes pour chaque cas dutilisation.
Point de dpart Interactions entre acteurs et objets du systme dfinies pour tous les cas
dutilisation et concepts mtiers dfinis dans la modlisation mtier.
Point darrive Classes et associations dfinies pour chaque cas dutilisation dans les DCL
par cas dutilisation.
Dmarche dlaboration
1 Identifier les classes du CU en prenant comme base les objets dfinis dans le diagramme de
squence du CU et les concepts mtiers.
2 Prciser les attributs des classes partir de ceux identifis dans le DSE (paramtres des
messages) et des entres de lIHM.
3 Prciser les oprations des classes partir des messages du DSE et des actions et activits du
DET. Un message entrant dun objet correspond une opration de la classe sollicite.

nom de lassociation,
multiplicit,
type dassociation (composition, agrgation, association qualifie, dpendance, hritage).
Recommandation :
Sassurer que le DCL de chaque CU reste lisible pour les acteurs mtiers au moins au niveau
du nom des classes et des principales relations.
Synthse de lanalyse
FICHE GUIDE FG13
Activit 4 : Synthse de lanalyse Projet :
Sous-activit 4.1 :
laboration du diagramme de classe rcapitulatif Date :
Objectif Regrouper lensemble des classes dans un seul diagramme pour avoir une
vision globale du systme tudi.
Point de dpart Tous les diagrammes de classe des cas dutilisation tudis.
Point darrive Regroupement des classes en un seul DCL.
Dmarche dlaboration
1 Rcuprer lensemble des DCL de tous les CU.
2 Mettre en commun, pour les mmes classes, les attributs et oprations de chaque classe
dfinis dans les DCL par CU. Chaque classe doit tre dcrite de manire exhaustive.
3 Mettre en commun toutes les associations entre les classes dfinies dans les DCL par CU.
4 Dterminer les relations entre diffrents DCL des CU. Mettre en place les nouvelles relations
ncessaires dans le DCL rcapitulatif.
Recommandation :
Sassurer que le DCL rcapitulatif reste lisible pour les acteurs mtiers au moins au niveau du
nom des classes et des principales relations. tablir, le cas chant, un DCL rcapitulatif deux
niveaux de lecture.
FICHE GUIDE FG14
Activit 4 : Synthse de lanalyse Projet :
Sous-activit 4.2 :
laboration de la matrice de validation Date :
Objectif Vrifier la compltude de lanalyse du systme et tablir la traabilit entre

les CU mtiers (activit exigences fonctionnelles) et les CU danalyse
(activit analyse des CU).
Point de dpart Les CU mtiers et danalyse.
Point darrive Compltude de lanalyse du systme vrifie et traabilit entre les CU

effectue.
Dmarche dlaboration
1 Reprendre les CU mtiers et danalyse.
2 tablir une correspondance entre les CU mtiers et les CU danalyse via la matrice de
validation.
NB : des cas dutilisation peuvent tre prsents uniquement dans lactivit danalyse des CU
car ils rpondent une problmatique spcifique lie par exemple la gestion des utilisateurs
par un administrateur.
3 Conclure sur la compltude de lactivit danalyse des CU en sassurant que tous les CU
mtier ont t repris dans lactivit danalyse des CU.
Recommandation :
Mettre en vidence (gras) dans la matrice, les CU qui nont pas pour origine un CU mtier.
Conception
FICHE GUIDE FG15
Activit 5 : Conception Projet :
Sous-activit 5.1 :
Ralisation des choix techniques Date :
Objectif Choisir larchitecture technique cible et les technologies associes.
Point de dpart tapes dexpression des besoins et danalyse termines

(Activits 1, 2, 3, 4).
Point darrive Architecture technique et technologies associes choisies.
Dmarche dlaboration
1 Choix de larchitecture technique en fonction des contraintes techniques imposes lors de

lexpression des besoins (ex. contraintes de performances), du contexte client (environnement
technique cible) et de ltat de lart des technologies.
2 Choix des technologies utilises en fonction de larchitecture slectionne et des contraintes

techniques.
NB : nous donnons, aprs les fiches guides, une description complmentaire sur cette sous-
activit.
Recommandation :
Ne pas ngliger la prise en compte des exigences techniques (contraintes de performances)
qui peuvent avoir une influence forte sur le choix dune architecture.
FICHE GUIDE FG16
Sous-activit 5.2 :
laboration des diagrammes de squence technique Date :
Objectif Reprsenter les interactions entre les acteurs et tous les objets du systme
(incluant les objets techniques) pour tous les cas dutilisation en considrant
les diffrents scnarios associs. Reprsenter les objets en utilisant la
classification dIvar Jacobson* (Dialogue, Contrleur, Entit).
* voir le paragraphe sur les complments de la conception.
Point de dpart Architecture choisie, DSE et DCL de lactivit 3.
Point darrive Interactions entre les acteurs et tous les objets du systme (incluant les
objets techniques) dfinies pour tous les cas dutilisation.
Dmarche dlaboration
Pour chaque cas dutilisation (CU) et chaque scnario identifi :
1 Reporter le ou les acteurs du DCU impliqus dans le scnario.
2 Reprsenter les objets du systme impliqus dans le scnario en prenant comme base ceux
identifis lors du DSE de lactivit 3 :
Objets Dialogue .
Objets Contrleur .
Objets Entit .
Objets techniques (Collection, Date) identifis uniquement lors de cette tape.
3 Reprsenter les messages (synchrones/asynchrones) entre les acteurs et les objets et entre
les objets eux-mmes. La chronologie des changes doit tre respecte.
4 Modliser les fragments dinteraction si ncessaire.
Recommandations :
1 Expliciter par des notes, les messages ou les fragments dinteractions complexes.
2 Utiliser des fragments dinteraction pour faciliter la lecture du DSE.
FICHE GUIDE FG17
Sous-activit 5.3 :
laboration des diagrammes de classe techniques Date :
Objectif Dfinir toutes les classes (incluant les classes techniques) et associations
pour tous les cas dutilisation. Reprsenter les classes en utilisant la
classification dIvar Jacobson (Dialogue, Contrleur, Entit).
Point de dpart Interactions entre les acteurs et tous les objets du systme (incluant les
objets techniques) dfinies pour tous les cas dutilisation et DCL de lactivit
3.
Point darrive Toutes les classes (incluant les classes techniques) et associations dfinies
pour tous les cas dutilisation.
Dmarche dlaboration

1 Reprsenter les classes du CU en prenant comme base les objets dfinis dans le diagramme
de squence technique du CU et le DCL de lactivit 3. Rpartir les classes en plusieurs
catgories :
Classes Dialogue .
Classes Contrleur .
Classes Entit (classes du DCL activit 3).
Classes techniques (Collection, Date) identifis uniquement lors de cette tape.
2 Prciser les attributs des classes et leurs caractristiques (visibilit, type, valeur initiale)
partir de ceux identifis dans le DSE (paramtres des messages).
3 Prciser les oprations des classes et leurs caractristiques (paramtres avec type, type de
rsultat) partir des messages du DSE.

Nom de lassociation.
Multiplicit.
Type dassociation (composition, agrgation, association qualifie, dpendance, hritage).
Contraintes (ordonnes, non ordonnes).
Recommandation :
Veiller regrouper dans la modlisation les classes dialogue , contrleur , et entit
pour une meilleure lecture du diagramme.
FICHE GUIDE FG18
Sous-activit 5.4 :
laboration du diagramme de paquetage Date :
Objectif Regrouper lensemble des classes en paquetage pour avoir une vision
globale et structure du systme tudi.
Point de dpart Tous les diagrammes de classe par cas dutilisation.
Point darrive Regroupement de lensemble des classes dans un seul diagramme de

paquetage.
Dmarche dlaboration
1 Regrouper lensemble des classes par ensemble homogne. Chaque ensemble correspond
un paquetage (ex . Gestion Mail). Lensemble peut correspondre un dcoupage technique
(archictecture en couches) ou fonctionnel.
2 Dterminer les dpendances entre les paquetages :

import
access

Recommandations :
1 Veiller respecter deux principes pour le regroupement des classes en paquetage :
Cohrence interne : constitution dun ensemble homogne fonctionnel/technique.
Faible couplage externe.
2 Ne pas reprsenter sur le DPA les dpendances import par transitivit.
4.5.3 Complments sur la conception

Deux points abords dans les fiches guides sur la conception mritent un
approfondissement :
En premier lieu, la sous-activit ralisation des choix techniques effectue
au dbut de lactivit de conception pour dterminer larchitecture technique
et les technologies associes. Cette sous-activit ne fait pas partie directement
du champ dUML et est fortement lie lvolution des technologies.
En second lieu, la classification dIvar Jacobson qui permet de rpartir les clas-
ses pour les diagrammes de lactivit de conception dans trois catgories
( dialogue , contrleur , et entit ).
Ralisation de choix techniques
Les choix techniques portent sur une architecture technique et des technologies
associes. Pour mieux comprendre les choix techniques raliser, nous allons
prendre lexemple du domaine du web. Pour cela, une prsentation des principales
architectures web est dtaille.
Larchitecture web la plus utilise aujourdhui est larchitecture multitiers (n-
tiers). Elle vient sopposer aux architectures plus anciennes comme larchitecture
mainframe et client/serveur par la rpartition des couches applicatives.
La structuration des applications en couches permet :
de matriser la complexit des applications (dveloppement, changes entre
les applications et interactions entre objets) ;
damliorer le dcouplage de lapplication ;
de diminuer les temps de dveloppement, en factorisant certaines briques
applicatives ;
de favoriser la communication :
lintrieur dune application, en structurant les changes entre les diff-
rentes couches ;
entre les applications, en prcisant les principes de communication lis aux
couches de diverses applications.
Deux principales architectures n-tiers sont utilises aujourdhui.
Larchitecture classique trois couches
Figure 4.7 Architecture classique trois couches

Les trois couches suivantes sont prsentes :

Couche prsentation Cette couche contient linterface homme-machine.
Cest la couche de prsentation des donnes lutilisateur. Elle contient
uniquement les pages de mise en forme des donnes en vue de leur affichage.
Couche domaine Cette couche contient les objets du domaine (facture, bon
de commande, client...). Ces objets encapsulent toutes les rgles mtier et
appliquent la logique fonctionnelle de lapplication.
Couche persistance Cette couche contient les usines dobjets mtier, cest-
-dire les classes charges de crer des objets mtier de manire totalement
transparente, indpendamment de leur mode de stockage (DAO, objet de
mapping).
Larchitecture oriente service (SOA)
Figure 4.8 Architecture oriente service (SOA)
Dans cette architecture, deux nouvelles couches apparaissent.

Couche coordination Cette couche gre lorganisation des donnes affi-
cher. Cest un contrleur qui gre lenchanement des pages afficher (Page
Flow) en fonction des diffrentes demandes formules par lutilisateur.
Couche services Cette couche gre laspect SOA de lapplication. Chaque
demande de lutilisateur correspond un service appel par cette couche, qui
appelle les couches infrieures, et renvoie le rsultat de son traitement la
couche suprieure. Cest galement la couche service qui gre les transactions.
Cette architecture prsente les spcificits suivantes par rapport aux architectu-
res classiques :
La couche coordination ne manipule plus directement les objets mtiers, mais
passe par des appels de services.
Les objets mtiers se trouvent dans des bibliothques de classe directement
charges dans le mme processus que les services ; le cot des appels aux objets
mtiers est alors trs faible.
Les services agissent comme des botes noires faisant abstraction de la
complexit du modle objet. Ces services prsentent un ensemble de fonc-
tionnalits restreintes et permettent de rduire les changes entre les couches.
Concernant les technologies utilises pour ces architectures, deux solutions

dominent le march : J2EE propose par Sun et .NET propose par Microsoft. Ces
solutions ne seront pas dtailles dans cet ouvrage.
Classification dIvar Jacobson

La classification dIvar Jacobson permet didentifier les classes dialogue ,
contrleur et entit dans un systme :
Les classes dialogue Elles servent modliser les interactions entre le
systme et ses utilisateurs. Les paramtres saisis par les utilisateurs peuvent
tre reprsents sous forme dattributs de classe. Les actions proposes lutili-
sateur sur chaque page sont reprsentes sous forme doprations nommes par
un verbe.
Elles ne peuvent tre quassocies uniquement aux classes contrleur ou
dautres classes dialogue .
Les classes contrleur Elles sont utilises pour reprsenter la coordina-
tion, lenchanement et le contrle dautres objets. Gnralement, une seule
classe contrleur par cas dutilisation. Mais sur le diagramme on peut
montrer quun contrleur appelle le contrleur dun autre cas dutilisation. Il
est possible de modliser les oprations effectues par le contrleur et dclen-
ches par des actions au niveau des dialogues ou priodiquement.
Elles peuvent tre associes tous les types de classe.
Les classes entit Elles servent modliser des informations durables et
souvent persistantes. Les classes entit sont issues des concepts mtier du
modle de domaine ou bien sont nouvellement cres dans le diagramme si ce
sont des entits purement applicatives ou techniques.
Les classes entit ne peuvent tre quassocies uniquement aux classes
contrleur ou dautres classes entit .
5
tude de cas n 1
Analyse
5.1 NONC DU CAS ALLOC
Chaque anne, au troisime trimestre, les directeurs de laboratoire de recherche

expriment leurs demandes de moyens pour lanne venir auprs de leur direction
scientifique. Une demande porte sur les moyens humains et sur les moyens finan-
ciers.
Chaque demande est tudie par la direction scientifique laquelle le laboratoire
est rattach.
Les propositions dallocation de moyens des directions scientifiques font ensuite
lobjet dune consolidation gnrale par un coordonnateur afin de soumettre ces pro-
positions larbitrage de la direction gnrale. Cet ultime arbitrage permet daboutir
une dcision dfinitive dallocation de moyens aux laboratoires.
Chaque directeur scientifique notifie ses laboratoires les dcisions dallocation
de moyens pour lanne n + 1.
Dans le cadre de cette premire tude cas, il est systmatiquement indiqu, pour chaque
diagramme ou activit produire, le numro de la fiche guide qui apporte un support
mthodologique la mise en uvre de la dmarche dUML (UP7) prconise dans cet
ouvrage.
150 Chapitre 5. tude de cas n 1 Analyse
5.2 MODLISATION MTIER
5.2.1 laboration du schma de contexte du domaine dtude (FG1)

Conformment notre dmarche UP7, nous recommandons dtablir en premier un
schma de contexte permettant de situer le domaine dtude par rapport aux autres
processus de lentreprise.
Ainsi, nous observons (fig. 5.1) que le domaine dtude est en troite relation
avec deux processus importants traitant respectivement les ressources humaines et
les moyens financiers.
Processus financiers
Processus ressources humaines
Allocation des moyens
Dcision d'attribution
Directeur d'unit
Figure 5.1 Schma de contexte du domaine dtude
5.2.2 laboration du diagramme dactivit (FG2)

Quatre acteurs principaux interviennent dans les processus dallocation des moyens
(fig. 5.2) :
Le directeur de laboratoire (DU) Cest lui qui exprime la demande de
moyens sa direction scientifique.
Le directeur scientifique (DS) Il instruit la demande et labore des propo-
sitions dallocation de moyens.
Le coordonnateur (CO) Il saisit les cadrages des moyens respecter par les
DS et consolide les propositions faites par les DS avant de les soumettre
larbitrage du DG. Il saisit ensuite les ventuels ajustements des cadrages aprs
les arbitrages.
La direction gnrale (DG) Elle arbitre dfinitivement les propositions
dallocation des moyens aux laboratoires aprs discussion avec les directeurs
scientifiques.
5.2 Modlisation mtier 151
DU DS CO DG
Cadrage
Exprimer
la demande Organiser instruction
[Cadrage saisi]
[Demande exprime]
Instruire
[Demande instruite] [Attribution propose]
Consolider proposition
[Cadrage ajust] [Attribution consolide]
Allouer moyens Arbitrer
[Attribution alloue] [Attribution arbitre]

Recevoir attributions
Figure 5.2 Diagramme dactivit du domaine
5.2.3 laboration du diagramme de classe mtier (FG3)

Les concepts mtier pris en compte dans le diagramme de classe mtier (fig. 5.3) sont :
Unit Laboratoire de recherche exprimant une demande annuelle de
moyens.
Demande de lunit Demande annuelle de moyens exprime par le direc-
teur de lunit.
Attribution des moyens Attribution de moyens propose par le DS et
ensuite arbitre par le DG.
Cadrage DS Enveloppe fixe par le DG pour chaque DS et type de moyens.
DS Dpartement scientifique de rattachement de lunit.
Histo-demandes Historique de toutes les demandes en ressources humaines

ou en ressources financires exprimes par lunit.
Histo-attributions Historique des attributions en ressources humaines ou
en ressources financires faites lunit.
Attributions-RH Attributions Cadrage-DS TypeMoyen

-gradeA -numAttrib cadrer -typemoyen
-DStypeMoyenC 1
-nombreA -dateAttrib 1..* -intitulTypemoyen
-cadrageA
-date arbitrage 1..* fixer
Attribution-RF allouer
+typeMoyenA 1..* 1
+montantA 1
0..*
DS
correspondre Unit
0..1 -codeDS
-code unit
Demande 1..* rattacher 1 -intitulDS
mettre -intitul unit
-numDemande -nom directeur
1..* 1 -adresse rue allouer-histoRH
-dateDemande Histo-attribution-RH
-adresse ville 1
-adresse code postal -numAttribHA-RH
1 1..*
allouer-histoRF -dateAttribHA-RH
-gradeHA-RH
1 1 -nombreHA-RH
Demande-RH Demande-RF
-gradeD -typeMoyensD demander-histoRH
-nombreD -montantD
-justificationD-RH -justificationD-RF demander-histoRF 1..*
1..* 1..* Histo-attribution-RF

InterfaceUtilisateur Histo-demande-RF Histo-demande-RH -numAttribHA-RF
-dateAttribHA-RF
-nom -numDemandeHD-RF -numDemandeHD-RH -typeMoyensHA-RF
-prenom -dateDemandeHD-RF -dateDemandeHD-RH -montantHA-RF
-id -typemoyensHD-RF -gradeHD-RH
-montanHD-RF -nombreHD-RH
Figure 5.3 Le diagramme de classe mtier
5.2.4 Extrait des documents de cadrage

Des exemples de cadrage sont donns ci-aprs.
Cadrage des moyens allouer pour lanne n
Dpartements Ressources humaines (RH) Ressources financires (RF) en k

scientifiques
Chercheurs Ingnieurs Budget Budget

de fonctionnement dquipement
Chimie 12 15 21 000 4 000
Physique 8 7 12 000 3 000
Sciences de la vie 22 25 63 000 11 000

5.3 Exigences fonctionnelles 153
Demande de moyens des units pour lanne n
Dpartements Ressources humaines (RH) Ressources financires (RF) en k

Chimie
Chercheurs Ingnieurs Budget Budget

de fonctionnement dquipement
Unit 1 2 3 1 000 500
Unit 2 1 2 800 200
Unit 3 1 2 900 700
En rsum, les quatre types de moyen considrs dans cette tude de cas sont :
RH-chercheurs,
RH-ingnieurs,
RF-budget,
RF-quipement.
5.3 EXIGENCES FONCTIONNELLES
5.3.1 laboration du diagramme des cas dutilisation systme (FG4)

Reprsentation du DCU
partir du diagramme dactivit et de la connaissance des besoins des acteurs, nous
laborons une vision gnrale des cas dutilisation du futur systme en produisant le
DCU systme (fig. 5.4).
Description gnrale des cas dutilisation

Cas dutilisation 0- Saisir demande Il sagit de la saisie des donnes de
la demande de moyens par les directeurs dunits (DU). Cette saisie ne fait pas
partie du champ dtude du systme car elle est prise en charge par un systme
dinformation existant. Il convient seulement de prvoir une interface
permettant de rcuprer les informations aprs saisie.
Cas dutilisation 1- Grer les cadrages Chaque anne des cadrages sont
fixs par le DG pour chaque DS et chaque type de moyens. Ces cadrages sont
saisis par le coordonnateur (CO). Aprs arbitrage par le DG, les cadrages
peuvent ventuellement tre ajusts.
Cas dutilisation 2- diter les fiches de demande Aprs intgration des
donnes saisies dans le systme, celles-ci doivent pouvoir tre consultes par
les personnes qui sont charges de leur exploitation. Cest ldition des fiches
de demande qui rpondra ce besoin.
0- Saisir la demande
DU
2- diter les fiches de demande
DS 3- Proposer les attributions de moyens
6- Notifier les moyens arbitrs

Utilisateur
DG
5- Enregistrer larbitrage DG des moyens
4- Grer les moyens proposs
CO
1- Grer les cadrages
Figure 5.4 Le diagramme des cas dutilisation systme
Cas dutilisation 3- Proposer les attributions de moyens Aprs tude

des demandes et compte tenu des moyens disponibles, les DS procdent
lattribution des moyens humains et financiers unit par unit. Ces attribu-
tions sont en fait considrer comme des propositions tant que larbitrage de
la direction gnrale na pas t rendu.
Cas dutilisation 4- Grer les moyens proposs La gestion des moyens
consiste en la consolidation gnrale des moyens attribuer et la production
de tableaux de bord de suivi.
Cas dutilisation 5- Enregistrer larbitrage DG des propositions Un
certain nombre de moyens ne peuvent tre attribus que si le directeur gnral
a donn son accord. Ce dernier doit tre enregistr dans le systme par le
coordonnateur.
Cas dutilisation 6- Notifier les moyens arbitrs Les moyens arbitrs
doivent tre communiqus aux units laide de courriers produits automati-
quement.
5.3.2 laboration du diagramme de squence systme (FG5)

Au stade de la description du niveau mtier, il est possible de donner une premire
reprsentation des diagrammes de squence (DSE) en considrant les interactions
entre les acteurs et le systme pris dans son ensemble. Ainsi, nous tablissons :
Le DSE du cas dutilisation 1 Grer les cadrages (fig. 5.5).
Le DSE du cas dutilisation 2 diter les fiches de demande (fig. 5.6).
Le DSE du cas dutilisation 3 Proposer les attributions de moyens
(fig. 5.7).
Le DSE du cas dutilisation 4 Grer les moyens proposs (fig. 5.8).
Le DSE du cas dutilisation 5 Enregistrer larbitrage DG des propositions
(fig. 5.9).
Le DSE du cas dutilisation 6 Notifier les moyens arbitrs (fig. 5.10).
<<systme>>
: ALLOC
: CO demanderChoisirTypemoyen( )
demanderSaisirCadrage(DS, typemoyen)
cran cadrage
saisirCadrage(nombre)
afficherCadrage( )
cadrage
modifierCadrage(nombre)
cadrage modifi
Figure 5.5 DSE du cas dutilisation

<<systme>>
: ALLOC
: DS_
demanderFiches(DS)
liste units
choisirUnits(listeUnits)
fiches de demande

<<systme>>
: ALLOC
demanderChoisirTypemoyen( )
: DS
demandeProposerAttribution(DS, typemoyen)
liste units
loop Pour toutes les units traiter

choisirUnit(codeUnit)
cran de saisie d'une attribution

saisirAttribution(nombre)
rsultat du contrle des donnes saisies

validerAttribution(codevalid)
attribution enregistre

3- Proposer les attributions de moyens
<<systme>>
: ALLOC
: CO
demanderChoisirTypemoyen( )
demandeConsoliderPropositions(typemoyen)
choix des rubriques du fichier
consoliderPropRubriques(listeRubriques)
fichier de consolidation

<<systme>>
: ALLOC
demanderSaisirArbitrage(DS, typemoyen)
cran arbitrage
saisirArbitrage(dateArbitrage)
confirmer arbitrage saisi
validerArbitrage(codeV)

5- Enregistrer larbitrage DG des propositions
<<systme>>
: ALLOC
: DS
demanderNotifierMoyens(DS)
fichier des lettres de notification

5.3.3 laboration du schma de navigation gnrale (FG6)

Lenchanement global des crans peut tre donn ce stade (fig. 5.11).
Gestion
des cadrages
dition
des fiches de demandes
Allocation des moyens

Proposition
d'attribution
Gestion
des moyens attribus
Arbitrage
des propositions
Notification
des moyens attribus
Figure 5.11 Schma de navigation gnrale

5.4 Analyse des cas dutilisation 159
5.4 ANALYSE DES CAS DUTILISATION

5.4.1 laboration du diagramme des cas dutilisation (FG7)
partir du premier DCU labor dans la partie exigences fonctionnelles , il est
possible daffiner maintenant lanalyse des diffrents cas. Cette analyse conduit
ajouter deux cas dutilisation.
Choisir type de moyens

Ce cas permet de dcrire une seule fois les actions lies au choix dun type de moyens
et de proposer aux autres cas dy recourir avec la fonction include si besoin.
Suivre lavancement des attributions

Ce cas est en fait une extension du cas n 4 avec lutilisation de la fonction
extend . Il permet au coordonnateur de disposer, quand cela est utile, des
tableaux de suivi des attributions. Le diagramme complet des cas dutilisation est
donn la figure 5.12.
Directeur d'unit
3- Proposer les attributions de moyens
<<include>>

DS
5- Enregistrer l'arbitrage DG des attributions

<<include>>
Utilisateur
DG
8- Suivre lavancement des attributions
<<extend>> 7- Choisir type de moyens
CO <<include>>
Point dextension
si besoin tableau de suivi

<<include>>
Figure 5.12 Diagramme des cas dutilisation
5.4.2 Description des cas dutilisation (FG8, FG9, FG11, FG12)

Pour la suite de ltude de cas, nous allons produire lanalyse des huit cas dutilisation :
Cas 1- Grer les cadrages
Cas 2- diter les fiches de demande
Cas 3- Proposer les attributions de moyens

Cas 4- Grer les moyens proposs
Cas 5- Enregistrer larbitrage DG des propositions
Cas 6- Notifier les moyens arbitrs
Cas 7- Choisir type de moyens
Cas 8- Suivre lavancement des attributions
Pour chaque cas dutilisation, les sous-activits suivantes de lactivit Analyse

des cas dutilisation sont ralises :
Description (textuelle) du cas dutilisation (FG8)
laboration du diagramme de squence (FG9)
laboration de linterface utilisateur (FG11)
laboration du diagramme de classe (FG12)
Cas dutilisation 1- Grer les cadrages

Description textuelle du cas dutilisation
Objectif Permettre au coordonnateur de saisir, de consulter ou de modifier
des donnes de cadrage pour un type de moyens.
Acteur concern Coordonnateur.
Pr condition Aucune.
Scnario nominal : saisie dun nouveau cadrage
1 Le coordonnateur choisit un type de moyen pour un DS donn.
2 Le coordonnateur renseigne les donnes de cadrage.
3 Le systme vrifie la prsence des donnes obligatoires.
4 Le systme affiche les donnes enregistrer pour validation.
5 Le systme enregistre la saisie valide.
2-a Modification des donnes de cadrage :
Le systme affiche le formulaire de saisie des donnes de cadrage enregis-
tres.
Le coordonnateur modifie les donnes.
2-b Consultation des donnes de cadrage :
Le systme affiche les donnes de cadrage dj enregistres.
Fin du cas dutilisation.
4-a Erreurs dtectes dans la saisie :
Le systme raffiche le formulaire de saisie en indiquant les erreurs dtec-
tes.
Le cas dutilisation reprend au point 3 du scnario nominal.
Description des diagrammes danalyse du cas dutilisation

La suite de lanalyse du cas dutilisation se poursuit par llaboration du diagramme
de squence (fig. 5.13), llaboration de linterface utilisateur (tab. 5.1) et llabora-
tion du diagramme de classe (fig. 5.14).
Dans le DSE, les cas derreurs ainsi que la recherche des intituls DS et type de
moyen nont pas t reprsents.
: InterfaceUtilisateur : Cadrage-DS
cran cadrage cran cadrage

saisirCadrage(nombre) saisirCadrage (nombre)
confirmerSaisie(accord)
validerSaisie(typemoyen, accord)
afficherCadrage(DS, typemoyen) afficherCadrage(DS, typemoyen)
cadrage cadrage
modifierCadrage(nombre)
modifierCadrage(DS, typemoyen, nombre)
cadrage modifi cadrage modifi
Figure 5.13 Diagramme de squence du cas dutilisation

Tableau 5.1 Donnes de linterface utilisateur du cas dutilisation 1
Donnes affiches Donnes saisies
- Code et intitul DS - DS et typemoyen
- Code et intitul du type de moyen traiter - Nombre correspondant au cadrage du type

de moyen slectionn
- Nombre correspondant au cadrage du type - Validation

de moyen slectionn
InterfaceUtilisateur Cadrage-DS DS
-nom -DStypeMoyenC -codeDS
-prenom -cadrageA fixer -intitulDS
-id -date 1
+saisirCadrage() 1..*
+afficherCadrage()
+afficherCadrage() +saisirCadrage()
+modifierCadrage() +validerSaisie()
+demanderChoisirTypemoyen() +modifierCadrage()
+confirmerSaisie() +demanderSaisirCadrage() cadrer
+demanderSaisirCadrage() 1..*
TypeMoyen
1
-typemoyen
-intitulTypemoyen
Figure 5.14 Diagramme de classe du cas dutilisation 1
Cas dutilisation 2- diter les fiches de demande

Objectif Permettre aux dpartements scientifiques de produire les fiches de
demande de moyens.
Une fiche de demande (FD) prsente un ensemble dinformation concernant
une unit donne. Elle regroupe lensemble de ses demandes pour lanne
N + 1. Un rappel de sa situation lanne N est aussi indiqu (en demande de
moyens et moyens attribus).
Acteur concern DS.
Pr condition Toutes les units du dpartement ont exprim leur demande.
Scnario nominal
Le DS demande ldition de fiches.
Le systme affiche les units du DS.
Le DS slectionne les units concernes.
Le systme construit et affiche le contenu de la fiche pour les units slec-
tionnes.

Cas dutilisation 3- Proposer les attributions de moyens

Objectif Permettre au DS de saisir ou de consulter des propositions dattri-
butions.
Acteur concern DS.
5.4 Analyse des cas dutilisation
: InterfaceUtilisateur : DS : Unit : Demande : Histo-Demande-RH : Histo-Attribution-RH : Histo-Demande-RF : Histo-Attribution-RF
: DS_ Pour toutes les units d'un DS

loop
demanderFiches(DS) llisterUnits(DS)
llisterUnits()
lliste units lliste units

choisirUnits(listeUnits)
loop Pour toutes les units de la liste
extraireFiche(codeDS, listeUnits)
extraireUnit(codeUnit)
extraireDemandeF()
extraireHistoD-RH()
extraireHistoA-RH()
extraireHistoD-RF()
extraireHistoA-RF()
fiches
fiches de demande
Figure 5.15 Diagramme de squence du cas dutilisation 2

163
- Code et intitul DS - DS
- Liste des units du DS - Codes units choisies
Pour chaque unit choisie :

- Nom du directeur
- Adresse
- Numro de demande
- Date de la demande
- Demandes RH et RF
- Historique demandes RH et RF
- Historique attributions RH et RF
DS
-codeDS rattacher
-intitulDS Histo-Attribution-RH Histo-Attribution-RF
1
+listerUnits() 1..* allouer-histoRH -numAttribHA-RH -numAttribHA-RF
+extraireFiche() -dateAttribHA-RH -dateAttribHA-RF
Unit -gradeHA-RH -typeMoyensHA-RF
1..*
-code unit -nombreHA-RH -montantHA-RF
1..*
Demande mettre -intitul unit 1 -extraireHistoA-RH() +extraireHistoA-RF()
-nom directeur
-numDemande 1..* 1 -adresse rue 1
-dateDemande allouer-histoRF
-adresse ville
+extraireDemandeF() -adresse code postal Histo-Demande-RH Histo-Demande-RF
+listerUnits() -numDemandeHD-RH -numDemandeHD-RF
-dateDemandeHD-RF
1 1..* -dateDemandeHD-RH -typemoyensHD-RF
-gradeHD-RH
1 demander-histoRH -nombreHD-RH -montantHD-RF
InterfaceUtilisateur
-justificationHD-RH -justificationHD-RF
-nom
+extraireHistoD-RH() +extraireHistoD-RF()
-prenom
-id
1..*
+demanderFiches()
+choisirUnits() demander-histoRF
Scnario nominal
1 Le DS choisit le type de moyen traiter.
2 Le systme affiche la liste des units du DS.
3 Le DS choisit lunit pour laquelle il veut faire une proposition dattribution.
4 Le systme affiche le formulaire de saisie des propositions dattribution pr
rempli avec les demandes du type de moyen slectionn effectues par lunit.
5 Le DS renseigne les donnes de la proposition dattribution.
6 Le systme vrifie la prsence des donnes obligatoires.
7 Le systme enregistre la saisie et affiche les attributions mises jour.
4-a Saisie dune proposition dattribution sans demande pralable
Le systme affiche le formulaire de saisie des propositions dattribution vierge.
4-b Modification dune proposition dattribution saisie
Le systme affiche le formulaire de saisie des propositions dattribution
avec les demandes et les propositions dattribution de lunit pr-remplies.
4-c Consultation des propositions dattribution
Le systme affiche les propositions dattribution de lunit slectionne
avec les demandes de moyens associes.
Fin du cas.
7-a Erreurs dtectes dans la saisie
Linstructeur corrige les erreurs.

: InterfaceUtilisateur : DS : Unit : Demande : Attributions
: DS_ demanderChoisirTypemoyen()
loop Toutes les units du DS
demanderProposerAttribution(DS, typemoyen) listerUnits(DS) extraireUnits()
unit extraite
liste units liste units
choisirUneunit(codeUnit) afficherSaisieAttribution(codeUnit, typemoyen)
extraireDemandeP(codeUnit, typemoyen)
cran de saisie d'une attribution
saisirAttribution(typemoyen, codeUnit, nombre)
contrlerAttribution(typemoyen, codeUnit, nombre)
rsultat du contrle des donnes saisies rsultat contrle
Dans le DSE, seul le scnario nominal est reprsent pour le traitement dune uni-
t. La recherche de lintitul DS et type de moyen na pas t traite.
- Code et intitul DS - DS et typemoyen
- Code et intitul du type de moyen traiter - Code de lunit traiter
- Demande RH - Nombre propos pour le type de moyens

- Demande RF trait
- Attribution propose RH - Validation de la saisie

- Attribution propose RF
Attributions
-numAttrib
correspondre -dateAttrib
0..* +contrlerAttribution()
-nom +validerAttribution()
-prenom
-id
DS
+saisirAttribution()
1..* -codeDS
+validerAttribution()
+demanderChoisirTypemoyen() -intitulDS
+demandeProposerAttribution() 0..1 allouer
+choisirUneunit() +listerUnits()
Demande rattacher
1 1
-numDemande
-dateDemande Unit
+extraireDemandeP() 1..*
-code unit
-intitul
-nom
i directeur
-adresse rue
-adresse ville TypeMoyen
-adresse code postal
mettre -typemoyen
+afficherSaisieAttribution() -intitulTypemoyen
+listerUnits()
Cas dutilisation 4- Grer les moyens proposs

Objectif Permettre au coordonnateur dexporter le fichier contenant les
lments relatifs aux demandes et aux propositions dattribution de moyens
pour llaboration des documents prsents au DG en vue de leur arbitrage.
Scnario nominal
1 Le coordonnateur choisit le type de moyen traiter.
2 Le coordonnateur demande extraire le fichier pour la consolidation des
propositions dattribution.
3 Le systme liste les diffrentes rubriques des propositions dattribution dans

le fichier
4 Le coordonnateur slectionne les rubriques souhaites.
5 Le systme gnre le fichier de consolidation des propositions dattribution
pour toutes les units.
: InterfaceUtilisateur : DS : Unit : Demande : Attributions
: CO demanderChoisirTypemoyen()
L'obtention de la liste des rubriques disponibles
demanderConsoliderPropositions(typemoyen)
demanderListeRubriques(typemoyen) pour unit et attributions n'est pas reprsente
choix des rubriques du fichier liste rubriques choisir
loop Pour tous les DS

consoliderPropRubriques(listeRubriques)
loo Pour toutes les units d'un DS

p
extraireMoyensP(typemoyen, listeRubriques)
extraireDemandeG(typemoyen, listeRubriques)
extraireDemandeG(typemoyen, listeRubriques)
extraireAttributionG(typemoyens, listeRubriques)
extraireAttributionG(typemoyen, listeRubriques)
moyens proposs d'un DS
fichier de consolidation de tous les DS
- Code et intitul type moyen - Type moyen
- Liste des rubriques du fichier - Liste des rubriques choisies
- Nombre correspondant aux demandes et aux

moyens proposs
Attributions
correspondre -numAttrib
-nom -dateAttrib
-prenom 0..*
-id +extraireAttributionG()
+consoliderPropRubriques()
+demanderConsoliderProposition() 0..*
allouer
+demanderChoisirTypemoyen() 0..1
Demande
emettre 1
-numDemande
0..* 1 Unit
-dateDemande
-code unit
+extraireDemandeG()
TypeMoyen -intitul unit
-nom directeur
-typemoyen
-adresse rue
-intitulTypemoyen
DS rattacher -adresse ville
1..* -adresse code postal
-codeDS
1 +extraireDemandeG()
-intitulDS
+demanderListeRubriques()
+extraireMoyensP()
+exraireAttributionG()
Cas dutilisation 5- Enregistrer larbitrage DG des propositions

Objectif Permettre au coordonnateur de saisir larbitrage de la direction.
Pr condition RAS
Scnario nominal
1 Le coordonnateur choisit un type de moyen pour un DS donn.
2 Le systme affiche le formulaire de saisie des tats darbitrage des types de
moyen pr rempli.
3 Le coordonnateur renseigne la date darbitrage.
4 Le systme vrifie la conformit des donnes saisies.
5 Le systme demande la validation des donnes saisies.
6 Le systme enregistre la saisie, aprs validation, et affiche le rsultat de la
mise jour.
5-a Erreurs dtectes dans la saisie :

: CO demanderChoisirTypemoyen()
demanderSaisirArbitrage(DS, typemoyen) afficherArbitrage(DS, typemoyen)
cran arbitrage
cran arbitrage
saisirArbitrage(dateArbitrage) modifierArbitrage(dateArbitrage)
arbitrage modifi
confirmer arbitrage saisi
validerArbitrage(codeV) validerArbitrage(codeV)
Seul le scnario nominal est reprsent dans le DSE. La recherche de lintitul

type moyen nest pas aussi reprsente.
- Code et intitul du type de moyen traiter - DS et type de moyen traiter
- Date de larbitrage - Date darbitrage

- Code validation
-nom Cadrage-DS
-prenom
-typeMoyenC
-id
-cadrageA
-date arbitrage TypeMoyen
+saisirArbitrage()
+demanderChoisirTypemoyen() cadrer
+afficherArbitrage() -typemoyen
+demanderSaisirArbitrage() -intitulTypemoyen
+validerArbitrage() 1..* 1
+validerArbitrage()
+modifierArbitrage()

Cas dutilisation 6- Notifier les moyens arbitrs

Objectif Permettre au DS de produire les lettres informant les directeurs
dunit des moyens qui leur sont allous.
Acteur concern DS.
Scnario nominal
1 Le DS demande lextraction du fichier pour ldition des lettres type dattri-
bution de moyens.
2 Le systme gnre le fichier des lettres de notification.
: InterfaceUtilisateur : DS : Unit : Attributions
: DS_
loop toutes les units du DS

demanderNotifierMoyens(DS)
notifierMoyens(DS) notifierMoyens() extraireAttributionN(typemoyen)
attributions d'une unit attributions d'une unit
fichier des lettres de notification

attribution de toutes les units
- Code et intitul du DS - Code du DS
Pour chaque unit concerne :

- Code
- Intitul
- Adresse
- Nom du directeur
- Type moyen et nombre correspondant au

moyen attribu (pour toutes les attributions).
Attributions-RH
-gradeA
Attributions -nombreA
-numAttrib Attribution-RF
-nom -dateAttrib
-prenom -typeMoyensA
-id +extraireAttributionN() -montantA
+demanderNotifierMoyens()
Unit
-code unit
0..*
-intitul unit DS
-nom directeur
-adresse rue 1..* 1 +codeDS
1 -adresse ville +intitulDS
-adresse code postal rattacher
+notifierMoyens()
allouer +notifierMoyens()
Cas dutilisation 7- Choisir un type de moyen

Objectif Permettre aux acteurs de choisir le type de moyen quils veulent
traiter.
Acteurs concerns Instructeur DS ou DG ou coordonnateur.
Pr condition RAS.
Scnario nominal
1 Le systme affiche la liste des types de moyen.
2 Lacteur concern choisit le type de moyen quil veut traiter.
Scnarios alternatifs Aucun.

: Utilisateur
demanderChoisirTypemoyen() listerTypemoyens()
liste des types de moyen
choisirUntypemoyen(typemoyen)

- Liste des types de moyen proposs - Code du type de moyen choisi
InterfaceUtilisateur Cadrage-DS
-nom -DStypeMoyenC
-prenom -cadrageA TypeMoyen
-id -date cadrage cadrer
-typemoyen
+demanderChoisirTypemoyen() +listerTypemoyens() 1..* 1 -intitulTypemoyen
+choisirUntypemoyen()
Cas dutilisation 8 Suivre lavancement des attributions

Objectif Mettre la disposition des dpartements scientifiques un ensemble
de tableaux de suivi des attributions des moyens aux units.
Pr condition tre lintrieur de lexcution du cas dutilisation n 4 :
Grer les moyens arbitrs.
Scnario nominal
1 Le systme affiche la liste des tableaux de suivi.
2 Le coordonnateur saisit le choix correspondant au tableau souhait.
3 Le systme produit le tableau de suivi demand.
5.5 SYNTHSE DE LANALYSE
Le diagramme de classe rcapitulatif (FG13) de la figure 5.29 intgre lensemble des

diagrammes de classe labors par cas dutilisation.
5.5 Synthse de lanalyse 173
: InterfaceUtilisateur : DS : Cadrage-DS : Unit : Attributions
: DS_
demanderTableauxdesuivi(typemoyen, DS)
afficher le choix des tableaux de suivi

construireTableaudesuivi(DS, typemoyen)
choisirUntableaudesuivi() extraireCadrage()
loop Toutes les units du DS

construireTableaudesuivi(typemoyen) donnerAttribution()
attributions dune unit

afficher le tableau de suivi attributions de
toutes les units
- Liste des tableaux de suivi - Choix du tableau de suivi
Attributions Cadrage-DS
-numAttrib -DStypeMoyenC
-dateAttrib 0..*
-cadrageA
+donnerAttribution() allouer -date arbitrage
+extraireCadrage()
1
Unit
InterfaceUtilisateur -code unit

-intitul unit
-nom -nom directeur 1..*
-prenom -adresse rue
-id -adresse ville fixer
-adresse code postal rattacher
+demanderTableauxdesuivi() 1
+choisirUntableaudesuivi() +construireTableaudesuivi()
1..*
1 DS
-codeDS
-intitulDS
+construireTableaudesuivi()

174
Attributions-RH Attributions Cadrage-DS 1..* 1 TypeMoyen InterfaceUtilisateur

cadrer
-gradeA -numAttrib -DStypeMoyenC -typemoyen
-intitulTypemoyen -nom
-nombreA -dateAttrib -cadrageA -prenom
-date arbitrage 1..* -id
+contrlerAttribution() er
Attribution-RF +donnerAttribution() 1
+extraireAttributionG() DS +choisirUneunit()
-typeMoyensA +demanderSaisirCadrage()
correspondre +extraiteAttributionN() +choisirUnits()
-montantA +validerAttribution() +extraireCadrage() -codeDS
-intitulDS +choisirUntableaudesuivi()
0..* +listerTypemoyens()
1..* +choisirUntypemoyen()
allouer +extraireFiche()
Demande 0..1
1 +extraireMoyenP() +consoliderPropRubriques()
-numDemande +saisirCadrage() +listerUnits() +demanderChoisirTypemoyen()
mettre
-dateDemande Unit +validerArbitrage() ens() +demanderConsoliderProposition()
0..* 1 +validerSaisie()
+extraireDemandeF() -code unit +demanderFiches()
rattacher 1 ens()
+extraireDemandeG() -intitul unit
+extraireDemandeP() -nom directeur 1..* +demanderProposerAttribution()
-adresse rue Histo-Attribution-RH +demanderSaisirCadrage()
-adresse ville -numAttribHA-RH +demanderTableauSuivi()
Demande-RH Demande-RF -adresse code postal 1 allouer-histoARH 1..* -dateAttribHA-RH
-gradeHA-RH +saisirArbitrage()
-gradeD -typeMoyensD +saisirAttribution()
+construireTableaudesuivi() -nombreHA-RH
-nombreD -montantD +saisirCadrage()
+demanderListeRubriques() 1 allouer-histoARF +extraireHistoA-RH() +validerArbitrage()
+extraireAttributionsG() +validerAttribution()
+extraireDemandeG() 1..*
Histo-Demande-RF +listerUnits() Histo-Demande-RH Histo-Attribution-RF
-numDemandeHD-RF ens()
-numDemandeHD-RH -numAttribHA-RF
-dateDemandeHD-RF 1..* 1..* -dateDemandeHD-RH -dateAttribHA-RF
-typemoyensHD-RF 1 -gradeHD-RH -typeMoyensHA-RF
-montantHD-RF 1
demander-histoDRF demander-histoDRH -nombreHD-RH -montantHA-RF
+extraireHistoA-RF()
+extraireHistoD-RF() +extraireHistoD-RH()
Figure 5.29 Diagramme de classe de synthse

Chapitre 5. tude de cas n 1 Analyse
6
tude de cas n 2
Analyse et conception
6.1 NONC DU CAS GESTION ACTIVIT ET FRAIS
La socit JeConseille, spcialise dans le conseil et laudit auprs de petites et

grandes entreprises, souhaite automatiser son systme de reporting dactivit et de
frais. Elle dsire que son nouveau systme soit accessible par tous ses employs lors de
leurs missions. Des niveaux de performances sont exigs : 100 connexions simulta-
nes et les temps de rponse pour chaque cran ne doivent pas dpasser 5 secondes.
Le fonctionnement actuel du systme repose sur la saisie dans un tableur, par les
employs, de rapports prvisionnels dactivit et de frais mensuels. Ces rapports con-
tiennent le nombre de jours travaills prvisionnels dans le mois, la rpartition par
projet (nombre de jours/par projet), le trajet prvisionnel ralis durant le mois (km)
et un cumul des frais () prvisionnel dpens durant le mois.
Ces rapports prvisionnels sont envoys la secrtaire de la division en dbut de
mois par messagerie. La secrtaire relance via la messagerie les employs nayant pas
fourni leurs rapports.
La secrtaire effectue par la suite une consolidation par division de tous les rap-
ports prvisionnels afin dobtenir une synthse des activits, des frais par projet et le
taux dactivit de la division.
Cette synthse est consulte par le manager de la division tous les mois.
Une modification de lactivit ou des frais dun consultant fait lobjet dune
modification du rapport enregistr et dun nouvel envoi de mail la secrtaire.
En fin de mois, la secrtaire reporte manuellement les informations ncessaires sur
les activits et les frais des employs dans le systme de facturation de lentreprise.
176 Chapitre 6. tude de cas n 2 Analyse et conception
Les fonctionnalits attendues sont dcrites dans ltape dexpression des besoins
de la dmarche UML.
6.2 MODLISATION MTIER
6.2.1 laboration du schma de contexte du domaine dtude (FG1)

Le schma de contexte du cas Gestion activit et frais est prsent la figure 6.1.
Gestion des frais Facturation

et des activits
Figure 6.1 Reprsentation du schma de contexte
Deux sous-ensembles et leurs dpendances sont modliss dans ce diagramme :

Gestion des frais et des activits Le sous-ensemble tudi tout au long de
ltude de cas.
Facturation Le sous-ensemble connexe dans lequel chaque mois sont trans-
mises les donnes des activits et des frais pour tablir la facturation de
lentreprise.
6.2.2 laboration du diagramme dactivit (FG2)

Le diagramme dactivit est donn la figure 6.2.
6.2 Modlisation mtier 177
Manager Employ Secrtaire Facturation
Grer frais Grer activit Relancer

activit
[Activit
relance]
Piloter activit
et frais [Frais
grs]
Communiquer activit
et frais
[Activit
gre]
[Activit [Frais
communique] communiqus]
Figure 6.2 Diagramme dactivit
Quatre acteurs sont identifis :

Employ Il gre son activit et ses frais chaque mois (cration, modification,
consultation).
Secrtaire Il ou elle1 relance les employs nayant pas cr leur activit. Elle
communique lactivit et les frais des employs au systme de facturation en
fin de mois.
Manager Il peut piloter lactivit et les frais de ses employs.
Facturation Cette entit correspond au systme de facturation de lentre-
prise qui reoit les activits et frais des employs en fin de mois.
6.2.3 laboration du diagramme de classe mtier (FG3)

Le diagramme de classe mtier est donn la figure 6.3.
1. Par simplification dcriture et en considrant le cas trait, nous avons pris lhypothse que le
poste de secrtaire est occup par une femme.
Profil
+libell
possde
Utilisateur Activit Date
1 +nom ralise +charge correspond +jour
1..*
+prnom +mois
+identifiant 1 1..* 1..* 1 +anne
appartient 1..* 1 1..* 1
1
Division engage se rapporte
+libell
0..* 1
Frais Projet
+montant se rapporte +code projet
+libell
0..* 1
0..*
correspond
Figure 6.3 Diagramme de classe mtier
Dfinition des concepts du domaine (glossaire mtier)

Utilisateur Ce concept englobe tous les acteurs utilisant lapplication.
Profil Les utilisateurs appartiennent diffrents profils (employ, secrtaire,
manager) qui ont des habilitations diffrentes sur lapplication.
Division Lentreprise est structure en plusieurs divisions, chacune ayant sa
spcificit (marketing, comptabilit...).
Activit Ce concept correspond la quantit de travail fournie par chaque
employ de lentreprise.
Frais Ce concept correspond aux diffrentes dpenses survenues pour
chaque employ dans le cadre de son activit.
Projet Ce concept correspond au moyen de mettre en uvre lactivit des
employs au sein de lentreprise.
Date Ce concept permet darchiver lactivit et les frais des employs de
lentreprise.
Les concepts mtiers dcrits sont illustrs sur les figures 6.4 et 6.5. Il sagit des for-
mulaires utiliss avant informatisation : le relev mensuel dactivit et le relev
mensuel de frais.
6.2 Modlisation mtier
Figure 6.4 Relev mensuel dactivit

179
Figure 6.5 Relev mensuel de frais
Figure 6.5 Relev mensuel de frai

6.3 EXIGENCES FONCTIONNELLES
6.3.1 laboration du diagramme des cas dutilisation systme (FG4)

partir du diagramme dactivit et de la connaissance des besoins des acteurs, nous
laborons une vision gnrale des cas dutilisation mtiers du futur systme (fig. 6.6).
System
Grer activit
Employ
Grer frais
Relancer activit
Secrtaire
Consulter tableaux de bord
Manager
Exporter activit et frais
<<Systme externe>>
Service Facturation
Figure 6.6 Diagramme des cas dutilisation systme
Description gnrale des cas dutilisation mtiers

Cas dutilisation 1- Grer activit Lemploy renseigne son activit en
dbut de mois pour les projets sur lesquels il va travailler. La description de
lactivit est ralise par journe. La secrtaire peut ainsi retrouver, pour une
journe donne, lactivit ralise par lemploy.
Un rcapitulatif de son activit sur le mois en cours ou sur les mois prcdents
est propos lemploy. Si lemploy ne peut renseigner son activit (maladie,
absence), la secrtaire est habilite renseigner son activit.
Cas dutilisation 2- Grer frais Lemploy renseigne ses frais prvision-
nels (frais kilomtriques, frais divers) en dbut de mois pour les projets sur
lesquels il va travailler.
La description des frais est ralise par journe. La secrtaire peut ainsi retrou-
ver pour une journe donne, les frais prvisionnels dun employ.
Un rcapitulatif de ses frais sur le mois en cours ou sur les mois prcdents est
propos lemploy. Si lemploy ne peut renseigner ses frais pour cause de
maladie ou absence, la secrtaire est habilite renseigner ses frais.
Cas dutilisation 3- Relancer activit La secrtaire relance par message-
rie, partir du 10 de chaque mois, les employs nayant pas ou partiellement
renseign leurs activits mensuelles. Si la secrtaire ne peut relancer lactivit,
le manager est habilit le faire sa place.
Cas dutilisation 4- Consulter tableaux de bord Le manager visualise
des tableaux de bord sur lactivit, les frais, et le taux dactivit pour un projet
donn ou une division donne et sur une priode donne.
Cas dutilisation 5- Exporter activits et frais la fin de chaque mois,
la secrtaire exporte les activits et les frais de tous les employs vers le service
facturation. Si la secrtaire ne peut exporter les activits et les frais, le mana-
ger est habilit le faire sa place.
6.3.2 laboration des diagrammes de squence systme (FG5)

Chaque cas dutilisation dcrit ci-dessus donne lieu un diagramme de squence
systme :
DSE du CU Grer activits (fig. 6.7)
DSE du CU Grer frais (fig. 6.8)
DSE du CU Consulter tableaux de bord (fig. 6.9)
DSE du CU Exporter activits et frais (fig. 6.10)
DSE du CU Relancer activit (fig. 6.11)
<<system>>
Gestion des frais
et activits
: Employ
loop
saisirActivit(charge,code projet,jour,mois,anne)
activit saisie
consulterActivit(mois)
Pour tous
les jours du mois
activits
Figure 6.7 DSE du CU Grer activits

<<system>>
Gestion des frais et activits
: Employ
loop
saisirFrais(montant,code projet,jour,mois,anne)
frais saisis
consulterFrais(mois)
Pour toutes
les activits avec frais
frais
Figure 6.8 DSE du CU Grer frais
<<system>>
: Manager
consulterTableaux(projet,mdebutPriode,adebutPeriode,mfinPriode, afinPriode )
alt
[debutPeriode
[dbutPriode = finPeriode
finPriode || debutPeriode
dbutPriode > finPeriode]
finPriode]
priode mal renseigne
[periode OK]
[priode
tableaux de bord
Dbut de priode identique

fin de priode
ou
dbut de priode plus rcente
que la fin de priode
Figure 6.9 DSE du CU Consulter tableaux de bord

<<system>>
: Secrtaire <<Systme externe>>

: Service facturation
exporterActivitFrais()
importerActivitFrais()
la fin de chaque mois
Figure 6.10 DSE du CU Exporter activits et frais
<<system>>
: Secrtaire
partir du 10 de chaque mois

relancerActivit()
activit relance
Figure 6.11 DSE du CU Relancer activit
6.3.3 laboration du schma de navigation gnrale (FG6)

Dans le cadre de lexpression des exigences fonctionnelles, lenchanement des
futurs crans de lapplication avec les habilitations des diffrents acteurs est prsent
sur la figure 6.12.
[ secrtaire ou manager ]
Tableaux de bord
[ manager ]
Exportation activit et frais
[ secrtaire ou manager ] Relance activit

Accueil
[ employ ou secrtaire ] Consultation frais
[ employ ou secrtaire ]
Saisie frais
Consultation activit
Saisie activit
Figure 6.12 Schma de navigation gnrale
6.4 ANALYSE DES CAS DUTILISATION
6.4.1 laboration du diagramme des cas dutilisation (FG7)

Ce diagramme de cas dutilisation (fig. 6.13) est plus dtaill que celui prsent au para-
graphe prcdent. En effet, nous sommes passs dans une phase danalyse qui corres-
pond une vue informatique du systme et nous avons identifi 13 cas dutilisation.
Saisir activit
Modifier activit
Employ Consulter activit
Saisir frais
Consulter frais
Secrtaire
Modifier frais
Relancer activit
Manager
<<Systme externe>>
Exporter activits et frais Service facturation

Administrateur
Crer utilisateur
Modifier utilisateur
Supprimer utilisateur
Grer rfrentiel
Figure 6.13 Diagramme des cas dutilisation
6.4.2 Description des cas dutilisation (FG8, FG9, FG11, FG12)

Pour la suite de ltude de cas, nous allons poursuivre lanalyse sur les cinq cas
dutilisation suivants seulement :
Saisir activit
Consulter activit
Relancer activit

Crer utilisateur
Pour chaque cas dutilisation, les sous-activits suivantes de lactivit Analyse

des cas dutilisation sont ralises :
Description du cas dutilisation (FG8)
laboration du diagramme de squence (FG9)
laboration de linterface utilisateur (FG11)
laboration du diagramme de classe (FG12)
Les scnarios alternatifs des cas dutilisation ont t modliss uniquement sur le
cas dutilisation Relancer activit .
Cas dutilisation Saisir Activit

Objectif - Saisir lactivit mensuelle de lemploy.
Acteur concern Lemploy.
Pr condition Lemploy sest authentifi correctement lapplication
Scnario nominal
1 Lapplication propose la saisie de la premire semaine du mois en cours.
2 Lemploy slectionne un ou plusieurs projets correspondant lactivit de
la semaine, puis saisit la charge consomme estime sur chaque projet. Cette
charge consomme est indique en jour.
3 Lemploy valide lactivit de la semaine.
4 Lemploy rpte les actions 1 3 pour toutes les semaines du mois traiter.
Scnario alternatif
2a Lemploy saisit une charge ngative pour un projet pour une journe don-
ne.
Lemploy saisit une charge ngative pour un projet sur une journe donne.
Lemploy valide lactivit de la semaine.
Lapplication avertit lemploy quune charge ngative a t saisie.
Le cas dutilisation reprend au point 2.
de squence (fig. 6.14), llaboration de linterface utilisateur (fig. 6.15) et llabora-
: Utilisateur : Activit : Projet : Date
: Employ
loop
saisirActivit(charge, code projet, jour, mois, anne)
<<create>>
Activit(charge, code projet, jour, mois, anne)
checkActivitePositive(charge)
getProjet(code projet)
projet
getDate(jour, mois, anne)
date
activit
pour toutes
les activits de la semaine
Figure 6.14 Diagramme de squence du CU Saisir activit
Saisir activit fvrier
S1 S2 S3 S4
Lundi Mardi Mercredi Jeudi Vendredi Samedi Dimanche
Code projet 1 0.5 0.5 1 1 1 4j
Code projet 2 0.5 0.5 1j
Total : 5 j
Ajouter un code
Valider
Figure 6.15 cran Saisir Activit

Date
-jour
-mois
-anne
+getDate(jour, mois, anne)
correspond
1..*
Utilisateur
-nom Activit
-prnom ralise -charge
-identifiant
-mot de passe 1 1..* +Activit(charge, code projet, jour, mois, anne)
+checkActivitePositive(charge)
+saisirActivit(charge, code projet, jour, mois, anne)
1..*
se rapporte
1
Projet
-code projet
-libell
Figure 6.16 Diagramme de classe du CU Saisir activit
Cas dutilisation Consulter activit

Objectif Pour un employ donn, avoir un rcapitulatif de lactivit sur le
mois en cours ou sur les mois prcdents.
Acteur concern Lemploy.
Pr condition Lemploy sest authentifi correctement lapplication.
Scnario nominal
1 Lemploy slectionne un mois.
2 Lapplication prsente lactivit mensuelle de lemploy avec la rpartition
entre les diffrents projets (si lemploy a particip plusieurs projets au
cours du mois).
3 Lapplication fait aussi un cumul global de lactivit mensuelle de lemploy,
puis des cumuls mensuels de lactivit par projet.
Scnario alternatif
2a : Lapplication ne peut prsenter lactivit car elle na pas t encore saisie
pour le mois slectionn.
Lapplication affiche un message indiquant quil ny a pas dactivit pour
le mois slectionn.
Lemploy revient sur la slection du mois. Le cas dutilisation reprend au
point 1.

de squence (fig. 6.17), llaboration de linterface utilisateur (fig. 6.18), et llabo-
ration du diagramme de classe (fig. 6.19).
: Utilisateur : Activit : Date
: Employ
getActivits(mois)
checkActivitMois(mois)
loop getDate()
comparerMois(mois)
activits
Pour toutes les activits enregistres,
calculTotalMoisActivit(mois) la mthode getActivits ne renvoie
que les activits du mois slectionn
cumul activit
Traitement identique celui de getActivits(mois)

avec en plus un cumul des charges.
Figure 6.17 Diagramme de squence du CU Consulter activit

Consulter activit
Slectionner un mois pour afficher le rcapitulatif de votre activit :
Mois : Mois
Valider
Consulter activit fvrier

L1 M2 M3 J4 V5 S5 D6 L7 M8 M9 J10 V11 S12 D13 L14 M15 M16 J17 V18 S19 D20 L21 M22 M23 J24 V25 S26 D27 L28
CP1 1 1 1 1 1
CP2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
Total : 21 j
Figure 6.18 cran Consulter slection activit
Date
-jour
-mois
-anne

+comparerMois(mois)
correspond
1..*
Utilisateur
-nom Activit
-prnom
-charge
-identifiant
ralise
-mot de passe +Activit(charge, code projet, jour, mois, anne)
1 1..* +getDate()
+checkActivitPositive(charge)
+getActivits(mois)
+calculTotalMoisActivit(mois)
+checkActivitMois(mois)
Figure 6.19 Diagramme de classe du CU Consulter activit

Cas dutilisation Relancer activit

Objectif Relancer, partir du 10 de chaque mois, les employs nayant pas
saisi leur activit du mois.
Acteur concern La secrtaire.
Pr condition La secrtaire sest authentifie correctement lapplication.
Scnario nominal
1 Lapplication prsente la liste des employs qui nont pas saisi (ou partiel-
lement) leur activit mensuelle.
2 La secrtaire valide cette liste.
3 Lapplication envoie un courriel de relance aux employs concerns.
1a Relance effectue avant le 10 du mois en cours.
Lapplication affiche un message indiquant que la relance ne peut avoir
lieu qu partir du 10 du mois. Le cas dutilisation se termine en chec.
1b Tous les employs ont rempli leur activit.
Lapplication affiche un message indiquant que tous les employs ont saisi
leur activit. Le cas dutilisation se termine en chec.
La suite de lanalyse du cas dutilisation se poursuit par llaboration de diagrammes
de squence (fig. 6.20 et 6.21), llaboration de linterface utilisateur (fig. 6.22), et
llaboration du diagramme de classe (fig. 6.23).
: Utilisateur
Vrification que le jour du mois
courant est > 10
: Secrtaire
getUtilisateursRelance()
checkDateMois() Vrification que tous les utilisateurs

ont saisi leur activit
checkAllActiviteComplete()
loop
isActiviteComplete(mois)
Pour chaque utilisateur, on regarde si lactivit est

complte pour le mois en cours. Si le retour de
utilisateursARelancer cette mthode est faux, il est ajout dans les
envoiMailUtilisateurs(listUtilisateurs) utilisateurs relancer.
loop
getMail()
envoiMail(mail)
Pour tous les utilisateurs relancer,

un mail de relance est envoy.
Figure 6.20 Diagramme de squence du CU Relancer activit

(scnario nominal)
Sur le mme DSE (fig. 6.21) sont reprsents le scnario alternatif 1a Relance
effectue avant le 10 du mois en cours et le scnario alternatif 1b Tous les em-
ploys ont rempli leur activit .
: Utilisateur
Vrification que le jour
du mois courant est > 10
: Secrtaire
checkDateMois()
erreur jour du mois courant < 10 Jour du mois courant > 10
checkDateMois()
Vrification que tous les utilisateurs

erreur ont saisi leur activit
Tous les utilisateurs

de l'application ont saisi
leur activit
Figure 6.21 Diagramme de squence du CU Relancer activit

(scnarios alternatifs)
Relancer activit fvrier
La liste des employs relancer :

Jean Dupont
Michel Durand
Pierre Martin
Jol Bernard
Marc Richard
Romain Dubois
Michal Simon
Dborah Robert
Laura Fournier
Julia Roux
Relancer
Figure 6.22 cran Relancer activit
Utilisateur
-nom
-prnom
-identifiant
-mot de passe
-mail
+getActivits(mois)
+checkActivitMois(mois)
+checkDateMois()
+getUtilisateursRelance()
+isActiviteComplete(mois)
+checkAllActivitComplte()
+envoiMailUtilisateurs(listUtilisateurs)
+getMail()
+envoiMail(mail)
Figure 6.23 Diagramme de classe du CU Relancer activit
Cas dutilisation Consulter tableaux de bord

Objectif Fournir au manager des tableaux de bord sur lactivit, les frais, le
taux dactivit pour un projet donn ou une division donne et sur une
priode donne.
Acteur concern Le manager.
Pr condition Le manager sest authentifi correctement lapplication.
Scnario nominal
1 Le manager slectionne une priode (mois, anne).
2 Lapplication propose des tableaux de bord sur la priode et la division du mana-
ger concernant lactivit par projet (nombre de jours/h par projet), le taux dacti-
vit (nombre de jour/h sur un projet / nombre de jour/h total de la priode).
3 Lapplication propose aussi un affichage de graphiques.
1a Le manager slectionne une priode errone (date dbut de priode est
suprieure la date de fin de priode ou date de dbut de priode est iden-
tique la date de fin de priode).
Lapplication prsente un message derreur sur la priode slectionne non
valide au manager. Le cas dutilisation reprend au point 1.
2a Aucun employ na rempli son activit et ses frais sur la priode slec-
tionne.
Lapplication affiche un message indiquant quaucun employ na saisi son
activit ou ses frais. Le cas dutilisation se termine en chec.
La suite de lanalyse du cas dutilisation se poursuit par llaboration de llaboration
du diagramme de squence (fig. 6.24), llaboration de linterface utilisateur
(fig. 6.25, fig. 6.26), et llaboration du diagramme de classe (fig. 6.27).
Par simplification, laffichage des graphiques nest pas trait sur le DSE figure 6.24
ni dans le reste de ltude de cas.
: Projet : Utilisateur : Activit : Division : Date
: Manager
calculNbJoursProjet(moisDebut, anneeDebut, moisFin, anneeFin, identifiant)
getUtilisateur(identifiant) Une somme de toutes les charges

par projet est ralise
Pour tous les projets si le projet appartient
getDivision() la priode slectionne
getCodeDivision()
loop
Si le projet appartient isProjetMemeDivision(code division)
la mme division
que le manager
opt
Pour toutes les activits loop

du projet getDate()
isDansPeriode(moisDebut, anneeDebut, moisFin, anneeFin)
opt
getCharge()
Un cumul des charges

par projet est retourn
calculTauxActivite(moisDebut, anneeDebut, moisFin, anneeFin, identifiant)
calculNbJoursTotalProjet(moisDebut, anneeDebut, moisFin, anneeFin, identifiant)
Mme traitement que CalculNbJousProjet

mais un cumul total des charges des projets
est retourn
calculNbjoursTotalPeriode(moisDebut, anneeDebut, moisFin, anneeFin)
nbJoursDansPeriode(moisDebut, anneeDebut, moisFin, anneeFin)
Le taux d'activit correspond au ratio

entre le rsultat de calculNbProjet
et de calculNbJoursTotalPeriode * 100
Figure 6.24 Diagramme de squence du CU Consulter tableaux de bord

Slection tableaux de bord
Slectionner une priode pour afficher les tableaux de bord pour la division Industrie :
Dbut priode : Mois Anne
Fin priode : Mois Anne
Valider
Figure 6.25 cran Slection tableaux de bord

La liste des projets et leurs activits pour la division Industrie sur la priode novembre/dcembre (effectif total :
10 personnes, dure de la priode : 40 j) :
Projet Activit (j/h)

Code projet 1 100
Code projet 2 80
Code projet 3 80
Code projet 4 30
Code projet 5 70
Taux dactivit de la division Industrie pour la priode novembre/dcembre :
Priode Taux dactivit de la division (%)

Novembre/dcembre 90
graphiques
Figure 6.26 cran Consulter tableaux de bord

Date
-jour
-mois
-anne

+comparerMois(mois)
+isDansPeriode(moisDebut, anneeDebut, moisFin, anneeFin)
+nbJoursDansPeriode(moisDebut, anneeDebut, moisFin, anneeFin)
correspond
Utilisateur
-nom 1..*
-prnom
-identifiant
-mot de passe Activit
-mail -charge
+saisirActivit(charge, code projet, jour, mois, anne) ralise +Activit(charge, code projet, jour, mois, anne)
+getActivites(mois) +modifier(charge)
+calculTotalMoisActivit(mois) 1 1..* +getDate()
+getUtilisateursRelance() +getCharge()
+isActiviteComplete(mois) +checkActivitePositive(charge)
+checkDateMois()
+checkAllActiviteComplete()
+envoiMailUtilisateurs(listUtilisateurs) 1..*
+getMail()
+envoiMail(mail)
+getUtilisateur(identifiant)
+getDivision()
se rapporte
1..*
appartient
Projet
1
-code projet
Division -libell
-code division est rattach +getProjet(code projet)

-libell +isProjetMemeDivision(code division)
1 1..* +calculTauxActivite(moisDebut, anneeDebut, moisFin, anneeFin, identifiant)
+getCodeDivision() +calculNbJoursProjet(moisDebut, anneeDebut, moisFin, anneeFin, identifiant)
+calculNbjoursTotalPeriode(moisDebut, anneeDebut, moisFin, anneeFin)
+calculNbJoursTotalProjet(moisDebut, anneeDebut, moisFin, anneeFin, identifiant)
Figure 6.27 Diagramme de classe du CU Consulter tableaux de bord

Cas dutilisation Crer utilisateur

Objectif Initialiser lapplication avec les utilisateurs.
Acteur concern Administrateur.
Pr condition Ladministrateur sest authentifi correctement lapplication.
Scnario nominal
1 Ladministrateur cre un utilisateur avec ses caractristiques : prnom, nom,
mail, profil.
2 Lapplication enregistre les informations renseignes et affiche un message
de confirmation.
3 Un mail est envoy lutilisateur cr avec son identifiant/password.
1a Ladministrateur saisit un nom ou un prnom avec des chiffres.
Lapplication affiche un message derreur prcisant que le nom ou prnom
sont des chanes de caractres uniquement. Le cas dutilisation reprend au
point 1.
1b Ladministrateur saisit un nom ou prnom suprieur 50 caractres.
Lapplication affiche un message derreur prcisant que le nom ou prnom
sont des chanes de caractres infrieures 50 caractres. Le cas dutilisation
reprend au point 1.
1c Ladministrateur saisit un mail erron (contrle sur le @).
Lapplication affiche un message derreur prcisant que le mail nest pas
valide. Le cas dutilisation reprend au point 1.
de squence (fig. 6.28), llaboration de linterface utilisateur (fig. 6.29) et llabora-
: Utilisateur
: Administrateur
<<create>>
Utilisateur(nom, prnom, profil, mail)
checkNomPrenom()
checkMail()
generateIdentifiantPassword()
envoiMail(mail)
Mail destin l'utilisateur

nouvellement cr
qui contient son identifiant
+ password
Figure 6.28 Diagramme de squence du CU Crer utilisateur
Crer utilisateur
Saisissez les informations relatives au nouvel utilisateur :
Prnom :
Nom :
Mail :
Profil : Profil Valider
Figure 6.29 cran Crer utilisateur

Utilisateur
-nom
-prnom
-identifiant
-mot de passe
-mail
+Utilisateur(nom, prnom, profil, mail)

+rechercheActivit(code projet, jour, mois, anne)
+supprimerActivit(code projet, jour, mois, anne)
+getActivits(mois)
+getUtilisateursRelance()
+isActivitComplte(mois)
+checkDateMois()
+checkAllActivitComplte()
+envoiMailUtilisateurs(listUtilisateurs
+getMail()
+envoiMail(mail)
+getUtilisateur(identifiant)
+getDivision()
+checkNomPrenom()
+checkMail()
+generateIdentifiantPassword()
Figure 6.30 Diagramme de classe du CU Crer Utilisateur
6.5 SYNTHSE DE LANALYSE
6.5.1 laboration du diagramme de classe rcapitulatif (FG13)

Ce diagramme de classe (fig. 6.31) intgre lensemble des diagrammes de classe
labors par cas dutilisation.
Profil
1 -code profil
-libelll
possde
+Profil(libell)
+modifier(libell)
+getCodeProfil()
+getLibell()
Date
6.5 Synthse de lanalyse
-jour
-mois
0..* correspond -anne
Utilisateur +Date(jour, mois, anne)

1 +getDate(jour, mois, anne)
-nom +setDate(jour, mois, anne)
-prnom +comparerMois(mois)
-identifiant 1..* +isDansPeriode(moisDebut, anneeDebut, moisFin, anneeFin)
-mot de passe +nbJoursDansPeriode(moisDebut, anneeDebut, moisFin, anneeFin)
-mail Activit
+Utilisateur(nom, prnom, profil, mail) -charge

+modifier(nom, prnom, profil, mail)
+saisirActivit(charge, code projet, jour, mois, anne) ralise +Activit(charge, code projet, jour, mois, anne) se rapporte
+modifier(charge) 1
+saisirFrais(montant, trajet, jour, mois, anne)
+modifierActivit(charge, code projet, jour, mois, anne) 1 1..* +getDate()
1..*
+modifierFrais(montant, code projet, jour, mois, anne) +checkActivitePositive(charge)
+rechercheActivit(code projet, jour, mois, anne) +getCharge()
+supprimerActivit(code projet, jour, mois, anne)
correspond
+rechercheFrais(code projet, jour, mois, anne)
+supprimerFrais(code projet, jour, mois, anne)
+getActivites(mois) 1
+calculTotalMoisFrais(mois) 0..*
Projet
+getFrais(mois) Frais
+checkDateMois() -code projet
+checkAllActiviteComplete() -montant -libell
+getUtilisateursRelance() -trajet
+isActiviteComplete(mois) engage +Projet(code projet, libell)
+Frais(montant, trajet, jour, mois, anne)
+envoiMailUtilisateurs(listUtilisateurs) +modifier(libell)
+getMail() +modifier(montant, trajet) 0..* 1 +getProjet(code projet)
1 0..* +getDate()
+envoiMail(mail) +getProjetsActivite(moisDebut, anneeDebut, moisFin, anneeFin, identifiant)
+getUtilisateur(identifiant) +isProjetMemeDivision(code division)
+getDivision() +calculTauxActivite(moisDebut, anneeDebut, moisFin, anneeFin, identifiant)
+checkNomPrenom() +calculNbJoursProjet(moisDebut, anneeDebut, moisFin, anneeFin, identifiant)
+checkMail() +calculNbjoursTotalPeriode(moisDebut, anneeDebut, moisFin, anneeFin)
+generateIdentifiantPassword()
1..*
1..*
Division
-code division
-libell
appartient 1
+creer(libell)
1 +modifier(libell) est rattach
+getCodeDivision()
+getLibell()
Figure 6.31 Diagramme de classe rcapitulatif

203
6.5.2 laboration de la matrice de validation (FG14)

La matrice de validation (fig. 6.32) permet de vrifier que lanalyse du cas est
complte, cest--dire que tous les cas dutilisation mtier ont t intgrs. Elle
permet aussi dtablir une correspondance entre les cas dutilisation mtier et les cas
dutilisation danalyse.
Cas dutilisation mtier Cas dutilisation analyse

Grer activits Saisir activit
Grer activits
Grer activits Consulter activit
Grer frais Saisir frais
Grer frais
Grer frais Consulter frais
Relancer activit Relancer activit
Consulter tableaux de bord Consulter tableaux de bord
Exporter activits et frais Exporter activits et frais
Crer utilisateur
Supprimer utilisateur
Grer rfrentiel
Figure 6.32 Matrice de validation
6.6 CONCEPTION
Pour rpondre aux contraintes techniques de lentreprise JeConseille ( Elle dsire

que son nouveau systme soit accessible par tous ses employs lors de leurs
missions ), la conception dun site web est ncessaire.
6.6.1 Ralisation des choix techniques et laboration des diagrammes

techniques (FG15, FG16, FG17)
Pour rpondre aux contraintes de performances ( 100 connexions simultanes et
les temps de rponse pour chaque cran ne doivent pas dpasser 5 secondes ) de
lnonc de ltude de cas, notre choix technique portera ainsi sur une architecture
oriente service (SOA) pour la conception du site web. En effet, comme prcis
dans la prsentation des architectures, les temps de rponse sont meilleurs du fait de
labstraction introduite par la couche service. Le cot des appels aux objets mtiers
partir de la couche service est trs faible.
6.6 Conception 205
Concernant, la technologie pour cette architecture, J2EE sera mise en place.

Cette solution ne sera pas dtaille dans cet ouvrage.
Pour chaque cas dutilisation, les sous-activits suivantes de lactivit
Conception sont ralises :
laboration du diagramme de squence technique (FG16),
laboration du diagramme de classe technique (FG17).
Cas dutilisation Saisir activit

Llaboration du diagramme de squence technique (fig. 6.33), et llaboration du
diagramme de classe technique (fig. 6.34) sont ralises.
: Dialogue Saisir Activit : CTRL Saisir Activit : Utilisateur : Activit : CollectionProjet
: Employ
saisirActivit(charges, dates, codes projet)
saisirActivit(charges, dates, codes projet)
checkActivitePositive(charges)
getUtilisateurActif()
Cette mthode a comme paramtre getIdentifiant()

la saisie de l'employ:
- une liste de charges
- une liste de dates (format date : jj/mm/aaaa)
<<create>>
- une liste de code projet loop Activit(charge, code projet, date, id utilisateur)
getProjet(code projet)
save()
Pour toutes les activits

Cette mthode fait appel au contexte
de la semaine
de l'application pour rcuprer l'utilisateur
actif (Session pour les applications Web).
Le contexte n'a pas t modlis ici.
Figure 6.33 Diagramme de squence technique du CU Saisir activit
La navigabilit des associations est donne par le sens de circulation des opra-
tions du diagramme de squence (fig. 6.33). Ainsi, la classe Dialogue Saisir
Activit accde la classe CTRL Saisir Activit par le biais du message saisi-
rActivit. La navigabilit des autres associations est dtermine sur le mme principe.
Une relation dagrgation existe entre la classe CollectionProjet et Projet
de type ensemble/lment , de plus une contrainte ordered indique que les
projets sont tris par code projet.
La contrainte ordered entre Utilisateur et Activit exprime la rela-

tion de tri par date croissante des Activit dans la collection Utilisateur .
CollectionProjet Projet
contient {ordered}
-code projet: String
+getProjet(code projet: String): String -libell: String
0..* 1..*
se rapporte
1..*
Utilisateur Activit
-nom: String
ralise {ordered} -charge: Float
-prnom: String -date: Date
-identifiant: String
1 1..*
-mot de passe: String +Activit(charge: Float, code projet: String, date: Date, id utilisateur:
+save(): void
+getIdentifiant(): String
1
1
1 1
<<Contrleur>>
CTRL Saisir Activit
Type Standard Date indpendant

+saisirActivit(charges: List, dates: List, codes projet: List): du langage de programmation
+checkActivitePositive(charges: List):
+getUtilisateurActif():
<<Dialogue>>
Dialogue Saisir
-charges: List
-codes Projet: List
+saisirActivit(charges: List, dates: List, codes projet: List):
Figure 6.34 Diagramme de classe technique du CU Saisir activit
Cas dutilisation Consulter Activit

Llaboration du diagramme de squence technique (fig. 6.35), et llaboration du
tions du diagramme de squence (fig. 6.34). Ainsi, la classe Dialogue Consulter
Activit accde la classe CTRL Consulter Activit par le biais du message
consulterActivit. La navigabilit des autres associations est dtermine sur le mme
principe.
6.6 Conception 207
: Dialogue Consulter Activit : CTRL Consulter Activit : Utilisateur : Activit : DateUtils
: Employ
getActivites(mois)
checkActiviteMois(mois)
loop getDate()
compareMois(date,mois)
List
calculTotalMoisActivit(mois) Pour toutes les activits saisies,

getActivites(mois) ne renvoie
que les activits du mois slectionn
Float
Traitement identique
List celui de getActivit(mois), avec
List en plus un cumul des charges
Le retour comprend la liste

des activits + le cumul
Figure 6.35 Diagramme de squence technique du CU Consulter activit
Une relation de dpendance est modlise entre la classe Utilisateur et la

classe technique DateUtils . On remarquera que le lien entre un objet
Utilisateur et DateUtils est momentan, il ne dure que le temps dexcution
de la mthode compareMois. Ainsi ce nest pas une association, mais une simple
dpendance.
DateUtils
+comparerMois(date: Date, mois): Boolean
Utilisateur
-nom: String Activit
-prnom: String
-charge: Float
-identifiant: String {ordered}
-date: Date
-mot de passe: String
1 1..* +Activit(charge: Float, code projet: String, date: DateUtils, id utilisateur: String )
+getActivites(mois: String): List
+save(): void
+getDate(): Date
+calculTotalMoisActivit(mois: String): Float
+checkActiviteMois(mois: String): Boolean
1
1
<<Contrleur>>
CTRL Consulter Activit
+consulterActivit(mois: String): List

+getUtilisateurActif(): Utilisateur
<<Dialogue>>
Dialogue Consulter Activit
-mois: String
+consulterActivit(mois: String): List
Figure 6.36 Diagramme de classe technique du CU Consulter activit
Cas dutilisation Relancer activit

Llaboration des diagrammes de squence technique (fig. 6.37, fig. 6.38), et llabo-
ration du diagramme de classe technique (fig. 6.39) sont ralises.
Sur le mme DSE (fig. 6.38) sont reprsents le scnario alternatif 1a : Relance
effectue avant le 10 du mois en cours et le scnario alternatif 1b : Tous les
employs ont rempli leur activit .
Vrification que le jour du mois
courant est > 10
: DateUtils : CollectionUtilisateur : Utilisateur : Mail

: Dialogue Relancer Activit : CTRL Relancer Activit
6.6 Conception
: Secrtaire
FindUtilisateursRelance()
FindUtilisateursRelance() checkDateMois()
getMoisCourant()
getUtilisateursRelance(mois)
loop
isActiviteComplete(mois)
RelancerActivit(listUtilisateurs) Pour chaque utilisateur, on vrifie si l'activit est

complte pour le mois slectionn, si c'est le cas
RelancerActivit(listUtilisateurs)
l'utilisateur est ajout la liste retourne.
envoiMailUtilisateurs(listUtilisateurs)
loop
getMail()
Figure 6.37 Diagramme de squence technique du CU Relancer activit (scnario nominal)

<<create>>
Mail(dest,body,from)
send()
Pour tous les utilisateurs retourns, un mail de

relance est envoy.
Figure 6.37 Diagramme de squence technique du CU Relancer activit (scnario nominal)

209
: Dialogue Erreur Relancer Activit : Dialogue Relancer Activit : CTRL Relancer Activit : DateUtils : CollectionUtilisateur
: Secrtaire
checkDateMois()
messageErreur
creer(messageErreur)
<<create>>
Le jour du mois courant

est < 10
checkDateMois()
messageErreur
creer(messageErreur)
<<create>>
Tous les utilisateurs de

l'application ont saisi leur activit
Figure 6.38 Diagramme de squence technique du CU Relancer activit

(scnarios alternatifs)
tions du diagramme de squence (fig. 6.38). Ainsi, la classe CTRL Relancer
Activit accde la classe Dialogue Erreur Relancer Activit par le biais du
message creer. La navigabilit des autres associations est dtermine sur le mme
principe.
6.6 Conception 211
Utilisateur
-nom: String
-prnom: String
Mail
-mail: String
-dest: String
+getActivites(mois: String): List
+getIdentifiant(): String -from: String
-body: String
+checkActiviteMois(mois: String): Boolean +Mail(dest: String, from: String, body: String)
0..* +isActiviteComplete(mois: String): Boolean +send(): void
+envoiMailUtilisateurs(listUtilisateurs: List): void
contient +getMail(): String
1
CollectionUtilisateur
1
+checkAllActiviteComplete(): Boolean
+getUtilisateursRelance(mois: String): List
1 1 1
<<Contrleur>>
CTRL Relancer Activit DateUtils
+FindUtilisateursRelance(): List +comparerMois(date: Date, mois): Boolean

+RelancerActivit(listUtilisateurs: List): void +checkDateMois(): Boolean
+getMoisCourant(): String
<<Dialogue>>
Dialogue Erreur Relancer Activit
<<Dialogue>> +messageErreur: String

Dialogue Relancer Activit +creer(messageErreur)
+mois: String
+FindUtilisateursRelance(): List
+RelancerActivit(listUtilisateurs: List): void
Figure 6.39 Diagramme de classe technique du CU Relancer activit
Une relation de dpendance est modlise entre la classe Utilisateur et la

classe technique Mail . On remarquera que le lien entre un objet Utilisateur
et Mail est momentan, il ne dure que le temps dexcution de la mthode Mail
et send. Ainsi ce nest pas une association, mais une simple dpendance.
Cas dutilisation Consulter tableaux de bord

Llaboration des diagrammes de squence technique (fig. 6.40) et llaboration du
212
: Dialogue Consulter TDB : CTRL Consulter TDB : CollectionProjet : Utilisateur : Division : Projet : Activit : DateUtils
: Manager
consulterTDB(moisDebut, anneeDebut, moisFin, anneeFin)
consulterTDB(moisDebut, anneeDebut, moisFin, anneeFin)
checkPeriodeSelect(moisDebut, anneeDebut, moisFin, anneeFin)
getDivision()
getCodeDivision()
Pour toutes les

activits du projet
calculNbJoursProjet(moisDebut, anneeDebut, moisFin, anneeFin, code division)
loop isProjetMemeDivision(code division)
Pour tous les projets cumulChargeProjet(moisDebut, anneeDebut, moisFin, anneeFin)

opt
loop getDate()
Si le projet appartient
la mme division que le isDansPeriode(date, moisDebut, anneeDebut, moisFin, anneeFin)
manager
opt
getCharge()
Un cumul des charges

par projet est retourn sous
forme de liste
List Une somme de toutes les charges

par projet est ralise
calculTauxActivite(moisDebut, anneeDebut, moisFin, anneeFin)
si le projet appartient la priode
slectionne
calculNbJoursTotalProjet(moisDebut, anneeDebut, moisFin, anneeFin, code division)
La liste retourne contient le cumul Mme traitement que CalculNbJousProjet

des charges par projet + taux activit nbJoursDansPeriode(moisDebut, anneeDebut, moisFin, anneeFin)
mais un cumul total des charges des projets est
retourn
Float
List
Figure 6.40 Diagramme de squence technique du CU Consulter tableaux de bord

Chapitre 6. tude de cas n 2 Analyse et conception
Utilisateur Activit
-nom: String -charge: Float
-prnom: String ralise {ordered} -date: Date
-mot de passe: String 1 1..* +Activit(charge: Float, code projet: String, date: Date, id utilisateur: String)
-mail: String +save(): void
+getDate(): Date
+getActivites(mois: String): List +getCharge(): Float
6.6 Conception
+checkActiviteMois(mois: String): Boolean 1..*
+isActiviteComplete(mois: String): Boolean
+envoiMailUtilisateurs(listUtilisateurs: List): void
+getMail(): String DateUtils
+getDivision(): Division
+comparerMois(date: Date, mois: String): se rapporte
+checkDateMois():
1..*
+isDansPeriode(date: Date, moisDebut, anneeDebut, moisFin, anneeFin): Boolean
+nbJoursDansPeriode(moisDebut, anneeDebut, moisFin, anneeFin): Integer
appartient
1
1
Projet
Division
-code projet: String
-code division: String 1 1..* -libell: String
-libell: String
est rattach +isProjetMemeDivision(code division: String): Boolean
+getCodeDivision(): String
1
{ordered} 1..*
contient
1
Figure 6.40 Diagramme de squence technique du CU
CollectionProjet
Figure 6.41 Diagramme de classe technique du CU Consulter tableaux de bord

+calculNbJoursProjet(moisDebut: String, anneeDebut: String, moisFin: String, anneeFin: String, code division: String): List
+calculTauxActivite(moisDebut: String, anneeDebut: String, moisFin: String, anneeFin: String): Float
+calculNbJoursTotalProjet(moisDebut: String, anneeDebut: String, moisFin: String, anneeFin: String, code division: String): Integer
1
<<Contrleur>
CTRL Consulter TDB
+consulterTDB(moisDebut: String, anneeDebut: String, moisFin: String, anneeFin: String): List

+checkPeriodeSelect(moisDebut: String, anneeDebut: String, moisFin: String, anneeFin: String)
+getUtilisateurActif(): Utilisateur
<<Dialogue>
Dialogue Consulter TDB
-moisDebut: String
-anneeDebut: String
-moisFin: String
-anneeFin: String
+consulterTDB(moisDebut: String, anneeDebut: String, moisFin: String, anneeFin: String): List
Figure 6.41 Diagramme de classe technique du CU Consulter tableaux de bord

213
tions du diagramme de squence prcdent. Ainsi, la classe Dialogue Consulter
TDB accde la classe CTRL Consulter TDB par le biais du message consulter-
TDB. La navigabilit des autres associations est dtermine sur le mme principe.
Une relation de dpendance est modlise entre la classe Projet et la classe
technique DateUtils . On remarquera que le lien entre un objet Projet et
DateUtils est momentan, il ne dure que le temps dexcution de la mthode
isDansPeriode. Ainsi ce nest pas une association, mais une simple dpendance.
Cas dutilisation Crer utilisateur

Llaboration des diagrammes de squence technique (fig. 6.42), et llaboration du
: CTRL Crer Utilisateur : Utilisateur : Mail : CollectionUtilisateur

: Dialogue Crer Utilisateur
: Administrateur
CreerUtilisateur(nom, prnom, mail, profil)
CreerUtilisateur(nom, prnom, mail, profil)
checkNomPrenom()
checkMail()
<<create>>
Utilisateur(nom,prnom,mail) Mail destin l'utilisateur
nouvellement cr
qui contient son identifiant
+ password
generateIdentifiantPassword()
Mail(dest, from, body)
send()
add(utilisateur)
Figure 6.42 Diagramme de squence technique du CU Crer utilisateur
tions du diagramme de squence prcdent. Ainsi, la classe Dialogue Crer
Utilisateur accde la classe CTRL Crer Utilisateur par le biais du message
creerUtilisateur. La navigabilit des autres associations est dtermine sur le mme
principe.
Utilisateur
-nom: String
-prnom: String
-mail: String
6.6 Conception
Mail
+Utilisateur(nom: String, prnom: String, mail: String)
+getActivites(mois: String): List -dest: String
+getIdentifiant(): String -from: String
+calculTotalMoisActivit(mois: String): Float -body: String
+checkActiviteMois(mois: String): Boolean
+isActiviteComplete(mois: String): Boolean +Mail(dest: String, from: String, body: String)
+envoiMailUtilisateurs(listUtilisateurs: List): void +send(): void
+getMail(): String
+getDivision(): Division
+generateIdentifiantPassword(): Boolean
contient 0..*
1 1
CollectionUtilisateur
+checkAllActiviteComplete(listUtilisateurs: List): Boolean

+add(utilisateur: Utilisateur): void
1 1
<<Contrleur>>
CTRL Crer Utilisateur
Figure 6.43 Diagramme de classe technique du CU Crer utilisateur

+CreerUtilisateur(nom: String, prnom: String, mail: String, profil: String): void
+checkNomPrenom(): Boolean
+checkMail(): Boolean
<<Dialogue>>
Dialogue Crer Utilisateur
-nom: String
-prnom: String
-mail: String
-profil: String
+CreerUtilisateur(nom: String, prnom: String, mail: String, profil: String): void
Figure 6.43 Diagramme de classe technique du CU Crer utilisateur

215
6.6.2 laboration du diagramme de paquetage (FG18)

Tous les paquetages de lapplication sont reprsents sur la figure 44 :
Dialogue Paquetage regroupant lensemble des classes permettant la gestion
des dialogues de lapplication :
Dialogue Saisir Activit.
Dialogue Consulter Activit.
Dialogue Relancer Activit.
Dialogue Erreur Relancer Activit.
Dialogue Consulter TDB.
Dialogue Crer Utilisateur.
Contrleur Paquetage regroupant lensemble des classes permettant la
gestion des contrleurs de lapplication :
CTRL Saisir Activit.
CTRL Consulter Activit.
CTRL Relancer Activit.
CTRL Consulter TDB.
CTRL Crer Utilisateur.
Entit Paquetage regroupant lensemble des classes mtiers de lapplication.
lintrieur de ce paquetage, une division en trois sous-paquetages est
prsente qui correspond un dcoupage fonctionnel.
Ces trois sous-paquetages sont les suivants.

Gestion des utilisateurs Paquetage regroupant lensemble des classes
permettant la gestion des donnes de lutilisateur :
CollectionUtilisateur.
Utilisateur.
Gestion activits et frais Paquetage regroupant lensemble des classes
permettant la gestion des donnes relatives aux activits et des frais :
Frais.
Activits.
Gestion du rfrentiel Paquetage regroupant lensemble des classes pouvant
tre administres :
CollectionProjet.
Projet.
Division.
Profil.
6.6 Conception 217
Deux paquetages techniques sont aussi reprsents sur le diagramme.

Gestion mail Paquetage regroupant lensemble des classes techniques
permettant la gestion des mails : Mail.
Gestion utilitaire Paquetage regroupant lensemble des classes techniques
utilitaires : DateUtils.
Les relations access dcrites figure 6.44 entre le paquetage Dialogue et Con-
trleur et entre le paquetage Contrleur et Entit illustrent lindpendance des cou-
ches du modle. En effet, les classes du paquetage Dialogue ont accs lespace de
nommage du paquetage Contrleur, mais cet accs ne se transmet pas par transiti-
vit. Les classes du paquetage ont accs lespace de nommage du paquetage Entit,
mais cet accs ne se transmet pas par transitivit au paquetage Dialogue.
Les relations import entre le paquetage Entit et GestionUtilitaire illustrent
bien le concept de transitivit. En effet, le paquetage Contrleur ayant accs
lespace de nommage du paquetage Entit a lui aussi accs au paquetage Gestion uti-
litaire.
Gestion utilitaire Gestion mail
<<import>> <<import>>
<<access>> <<access>> Entit

Dialogue Contrleur
Gestion activits et frais
<<import>> <<import>>
Gestion utilisateur Gestion rfrentiel
Figure 6.44 Diagramme de paquetage

Annexes
A. RCAPITULATIF DES CONCEPTS DUML 2
titre de synthse, il est propos dans cette annexe une liste rcapitulative des
concepts dUML 2 prsents dans cet ouvrage.
Ce rcapitulatif est donn par diagramme aprs un rappel des concepts communs.
Il peut aider le lecteur mmoriser les diffrents concepts mis en uvre dans chaque
diagramme.
Concepts communs tous les diagrammes
strotype,
mot-cl,
note,
contrainte.
Concepts du diagramme de classe (DCL)
attribut,
opration,
visibilit,
association,
navigabilit,
classe et classe abstraite,
rle,
multiplicit,
dpendance,
220 UML2 analyse et conception
agrgation et composition
qualification,
gnralisation et spcialisation,
hritage.
Concepts du diagramme dobjet (DOB)
objet,
lien,
valeur dattribut.
Concepts du diagramme de composant (DCP)
composant,
connecteur,
port,
interface requise, interface fournie,
dpendance,
compartiment.
Concepts du diagramme de dploiement (DPL)
nud,
unit de traitement ( device ),
environnement dexcution ( executionEnvironment ),
artefact,
spcification de dploiement.
Concepts du diagramme de paquetage (DPA)
espace de nommage,
dpendance de type import ,
dpendance de type access ,
dpendance de type merge .
Concept du diagramme de structure composite (DSC)
collaboration dinstances,
rle (dans la collaboration).
Diagramme des cas dutilisation (DCU)
acteur,
interaction,
scnario nominal,
scnario alternatif,
pr et post condition,
inclusion, extension, gnralisation de cas dutilisation.
Concept du diagramme tat-transition (DET)
tat,
transition,
vnement,
composition dtat (tat composite),
Annexes 221
point dentre et de sortie,

point de jonction,
point de choix,
tat historis.
Concepts du diagramme dactivit (DAC)
action,
activit,
flot de contrle,
flot de donnes,
nud de bifurcation,
nud de jonction,
nud de test-dcision,
nud de fusion-test,
nud de donnes,
pin dentre et de sortie,
partition (couloir dactivits).
Concepts du diagramme de squence (DSE)
ligne de vie,
message synchrone et asynchrone,
fragment dinteraction,
oprateur,
interaction,
oprateur alt,
oprateur opt,
oprateur loop,
oprateur par,
oprateurs strict/weak,
oprateur break,
oprateurs ignore/consider,
oprateur critical,
oprateur negative,
oprateur assertion,
oprateur ref.
Concepts du diagramme de communication (DCO)
rle,
tat,
message.
Concepts du diagramme global dinteraction (DGI)
ceux du DAC et les fragments dinteraction du DSE.
Concepts du diagramme de temps (DTP)
ligne de temps,
tats (temporels).
B. RCAPITULATIF DE LA DMARCHE UP7
Un rcapitulatif des activits et des fiches guides de la dmarche UP7 proposes dans
cet ouvrage est donn dans cette annexe.
Liste des activits de la dmarche
1 Modlisation mtier
2 Exigences fonctionnelles
3 Analyse des cas dutilisation
4 Synthse de lanalyse
5 Conception
6 Implmentation
7 Test
Liste des fiches guides associes aux activits
FG1 laboration du schma de contexte du domaine dtude
FG2 laboration du diagramme dactivit
FG3 laboration du diagramme de classe mtier
FG4 laboration du diagramme des cas dutilisation systme
FG5 laboration des diagrammes de squence systme
FG6 laboration du schma de navigation gnrale
FG7 laboration du diagramme des cas dutilisation
FG8 Description des cas dutilisation
FG9 laboration des diagrammes de squence
FG10 laboration des diagrammes dtat-transition
FG11 laboration des interfaces utilisateur
FG12 laboration des diagrammes de classe
FG13 laboration du diagramme de classe rcapitulatif
FG14 laboration de la matrice de validation
FG15 Ralisation des choix techniques
FG16 laboration des diagrammes de squence technique
FG17 laboration des diagrammes de classe technique
FG18 laboration du diagramme de paquetage
Bibliographie
[Barbier2005] Franck BARBIER, UML 2 et MDE, Dunod, 2005

[Bersini2004] Hughes BERSINI, Lorient Objet, Eyrolles, 2004.
[Blaha2002] Michael BLAHA, James RAMBAUGH Modlisation et conception orien-
tes objet avec UML 2, Pearson Education, 2005.
[Booch1994] Grady BOOCH, Object-Oriented Analysis and Design with Application,
Addison-WESLEY, 1994.
[Cockburn2001] Alistair COCKBURN, Rdiger des cas dutilisation efficaces, Eyrolles,
2001.
[Fowler2004a] Martin FOWLER, UML 2.0, Campus Press, 2004.
[Fowler2004b] Martin FOWLER, Initiation aux aspects essentiels de la notation, Campus
Press, 2004.
[Jacobson1992] Ivar JACOBSON, Grady BOOCH, James RUMBAUGH, The Unified
Modeling Language, Reference Manual, Addison-WESLEY, 1992.
[Jacobson2000a] Ivar JACOBSON, Grady BOOCH, James RUMBAUGH, Le Proces-
sus unifi de dveloppement logiciel, c/o Eyrolles, 2000.
[Jacobson2000b] Ivar JACOBSON, Grady BOOCH, James RUMBAUGH, Le guide
utilisateur UML, Eyrolles 2000.
[Kruchten2000] Philippe KRUCHTEN, The rational Unified Process An introduction,
Addison-WESLEY 2000.
[Muller2000] Pierre-Alain MULLER, Nathalie GAETNER, Modlisation objet avec
UML, Eyrolles, 2000.
[Meyer2000] Bertrand MEYER, Conception et programmation orientes objet, Eyrolles,

2000.
[OMG2007] OMG (Object Management Group), UML 2.0 Superstructure, http://
www.uml.org, 2007.
[Rumbaugh1991] James RUMBAUGH, Michael BLAHA, William PREMERLANI,
Frederick EDDY, William LORENSEN, Object-Oriented Modeling and Design, Pren-
tice Hall International, 1991.
[Rumbaugh2004] James RUMBAUGH, Ivar JACOBSON, Grady BOOCH, UML 2.0
Guide de rfrence, CampusPress, 2004.
[Scott2004] Ambler SCOTT, The elements of UML 2.0 style, Cambridge Press, 2004.
Index
Index
A de structure composite 11, 58
de temps 12, 109
acteur 62
action 73, 81 des cas dutilisation 11, 61
activit 73, 82, 113, 128 global dinteraction 12, 106
agrgation 3, 27, 28 structurel 11
analyse 116
des cas d'utilisation 125, 134 E
artefact 51, 53, 114 laboration 115
association 3, 23 encapsulation 3
attribut 19, 22 environnement 122
tat 2, 72
B-C composite 75
bote historique 77
blanche 48 exigences fonctionnelles 125, 131
noire 47 expression des besoins 116
cas dutilisation 62
classe 2, 18 F
abstraite 33 fiche guide 128
classe-association 27 flot
collaboration 58 de contrle 81
compartiment 48
composant 46
de donnes 86
composition 28 fragment dinteraction 93
conception 117, 126, 142, 146
connecteur G
dassemblage 47 gnralisation 4, 32
dinterfaces 47 gestion
construction 116 dun projet 122
contrainte 10, 26 de l'environnement 122
temporelle 92 de la configuration et des changements
122
D des exigences 121
dpendance 30
dinterfaces 47 H-I
entre paquetages 56 hritage 32
dploiement 121 implmentation 117
diagramme inception 115
dactivit 11, 80 incrmental 112
dtat-transition 11, 72, 73 instance 18
dobjet 11 interaction 63
de classe 11, 17 interface 31, 47
de communication 12, 104 itratif 112
de comportement 11 itration 116
de composant 11, 46
de dploiement 11, 50 J-L
de paquetage 11, 54 jalon 119
de squence 11, 90 ligne de vie 91
M de jonction 76
polymorphisme 4
message 91, 104
port 49
mta-modle 8
post condition 67
modlisation mtier 121, 124, 128
modularit 6 pr condition 67
multiplicit 24 priv 22
processus 112, 119
N profil 9
protg 22
navigabilit 25 public 22
nud 50, 53
de bifurcation 82 Q-R
de fusion-test 85 qualification 30
de jonction 83 qualit 118
de test-dcision 84 relation
note 10 dextension 65
dinclusion 64
O
de gnralisation 65
objet 2, 17, 21, 72, 105 rutilisabilit 6
OCL 10 risques 113
oprateur rle 24, 58, 104, 113
alt 94 RUP 117
assertion 100
break 97 S
consider 98 scnario
critical 98 alternatif 67
ignore 98 nominal 67
loop 94 spcialisation 4
negative 100 spcification de dploiement 51
opt 94 strotype 9, 36
par 96 synthse de l'analyse 125, 140
ref 100
srict 97 T-U
weak 97 tests 117
opration 20, 22 transistion 116
transition 72, 80, 81
P UML 7
paquetage 22, 54 UP 8, 111
partition 87 UP7 123
persistance 5 V-W
phase 114
pin 86 valeur marque 9
point visibilit 22
de choix 76 workflow 114, 119
INFOPRO L'ESSENTIEL
TYPE DOUVRAGE
SE FORMER
RETOURS
D'EXPRIENCE
MANAGEMENT DES SYSTMES

D'INFORMATION
APPLICATIONS
MTIERS
Joseph Gabay
TUDES, DVELOPPEMENT,
David Gabay INTGRATION
EXPLOITATION
ET ADMINISTRATION
UML 2 RSEAUX
& TLCOMS
Mise en uvre guide avec tudes de cas
Cet ouvrage sadresse tous les professionnels, concepteurs et JOSEPH GABAY

est directeur de projet
dveloppeurs, qui souhaitent mieux matriser UML 2 et acqurir informatique au CNRS.
une dmarche pratique de mise en uvre ainsi quaux tudiants Il assure galement des
enseignements dUML
en informatique. luniversit de Paris-
Dauphine ainsi quen
Il propose une approche pdagogique de laspect normatif dUML 2 IUT en en cycle BTS.
et une dmarche dlaboration des diagrammes couvrant lanalyse Il est lauteur de
plusieurs ouvrages
et la conception des systmes dinformation. Le lecteur suit un sur UML.
apprentissage progressif fond sur de nombreux exemples, exercices
corrigs et de vritables tudes de cas se rapprochant de projets
DAVID GABAY
rels dentreprise.
est ingnieur
Cette dition sert trois objectifs : et chef de projet
chez CapGemini.
prsenter les treize diagrammes dUML 2 en conciliant le respect
strict de la norme avec une application centre sur les SI des
entreprises ;
dcrire lanalyse et la conception des SI laide des diagrammes
dUML 2 en sappuyant sur des exemples et des exercices adapts
au contexte professionnel ;
proposer une dmarche de mise en uvre dUML 2 structure
en phases et activits, dcrite laide de fiches guides et illustre
par deux tudes de cas dtailles.
ISBN 978-2-10-053567-5 www.dunod.com

(Livre-Technique - Com) UML 2 Analyse Et Conception

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

(Livre-Technique - Com) UML 2 Analyse Et Conception

Transféré par

Droits d'auteur :

Formats disponibles

UML 2

Mise en uvre guide

Mise en uvre guide

Illustration de couverture : Mountain, DAJ, Hokkaido

Dunod, Paris, 2008

Chapitre 1 Concepts de lapproche objet et prsentation dUML 2 . . . . . . . . 1

1.1 Concepts de lapproche objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapitre 2 Les diagrammes structurels (ou statiques). . . . . . . . . . . . . . . . . . . 17

2.1 Diagramme de classe (DCL) et diagramme dobjet (DOB) . . . . . . . . . . . . . . 17

2.1.3 Association, multiplicit, navigabilit et contraintes . . . . . . . . . . . . . . . . . . 23

Chapitre 3 Les diagrammes comportementaux . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.1 Diagramme des cas dutilisation (DCU). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.3 Diagramme dactivit (DAC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Chapitre 4 Dmarche de dveloppement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

4.5 Dmarche de dveloppement UP7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Chapitre 5 tude de cas n 1 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Chapitre 6 tude de cas n 2 Analyse et conception . . . . . . . . . . . . . . . . . . . . 175

6.1 nonc du cas Gestion activit et frais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

6.5 Synthse de lanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

UML, une volution majeure dans le domaine des mthodes

Notre double comptence de professionnel de la conception et du dveloppe-

Le chapitre 2 traite les six diagrammes structurels : diagramme de classe,

Des exemples et exercices corrigs sont associs la prsentation de la plupart des

Le chapitre 4 porte sur la dmarche que nous proposons de mettre en uvre

qui sadresse ce livre ?

1.1 CONCEPTS DE LAPPROCHE OBJET

Nous nutiliserons pas, par contre dans ce chapitre, de formalisme particulier de

1.1.1 Objet et classe

1.1.2 Encapsulation et interface

1.1.3 Association et agrgation entre les classes

2- Oprations non accessibles

Figure 1.1 Schma de principe de lencapsulation

1.1.4 Gnralisation et spcialisation de classe

En fait lors de lexcution, lappel de lopration va automatiquement dclencher

1.1.7 Avantages du dveloppement laide des langages objet

1.2 PRSENTATION GNRALE DUML

Les grandes tapes de la diffusion dUML peuvent se rsumer comme suit :

1.2.2 Structuration de la prsentation

La prsentation de la dmarche que nous proposons UP7 sappuie fortement sur

1.2.3 Rgles gnrales

Le mta-modle dUML est compltement dcrit dans la norme.

Figure 1.2 Exemple dune classe strotype

Figure 1.3 Formalisme et exemple dutilisation dune note

Dans UML, un langage spcifique dexpression de contraintes est disponible ;

Figure 1.4 Exemple dutilisation dune contrainte

1.2.4 Prsentation gnrale des diagrammes

Diagramme de communication (anciennement appel collaboration) Ce dia-

Figure 1.5 Exemple de diagramme des cas dutilisation

Figure 1.6 Exemple de diagramme de classe

Le diagramme de squence va nous permettre de dcrire les scnarios des cas

Figure 1.7 Exemple de diagramme de classe

Cette premire illustration de trois diagrammes donne dj un clairage sur les

1.2.5 Schma densemble des treize diagrammes dUML 2

Description du systme Vues

Architecture technique DSC

Description des lments de la modlisation

Figure 1.8 Schma densemble des treize diagrammes dUML 2

2.1 DIAGRAMME DE CLASSE (DCL) ET DIAGRAMME

Figure 2.1 Exemples dobjets physiques et dobjets de gestion

2.1.2 Classe, attribut et opration

Formalisme gnral et exemple

Deux autres compartiments peuvent tre aussi indiqus :

Il est possible de manipuler les classes en limitant le niveau de description un