Uml 2 Analyse Et Conception (Dunod)

UML 2
ANALYSE ET CONCEPTION
Algeria-Educ.com
Mise en uvre guide avec tudes de cas
TUDES
DVELOPPEMENT
Joseph Gabay David Gabay
ANALYSE ET CONCEPTION
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapitre 1 Concepts de lapproche objet et prsentation dUML 2 . . . . . . . . 1.1 Concepts de lapproche objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 1.1.2 1.1.3 1.1.4 1.1.5 1.1.6 1.1.7 1.2.1 1.2.2 1.2.3 1.2.4 1.2.5 Objet et classe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Encapsulation et interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Association et agrgation entre les classes. . . . . . . . . . . . . . . . . . . . . . . . . . Gnralisation et spcialisation de classe . . . . . . . . . . . . . . . . . . . . . . . . . . Polymorphisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Persistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Avantages du dveloppement laide des langages objet . . . . . . . . . . . . . . . Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Structuration de la prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rgles gnrales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prsentation gnrale des diagrammes . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schma densemble des treize diagrammes dUML 2 . . . . . . . . . . . . . . . . .
IX 1 1 2 3 3 4 4 5 6 6 6 7 8 11 14 17 17 17 18
1.2 Prsentation gnrale dUML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapitre 2 Les diagrammes structurels (ou statiques). . . . . . . . . . . . . . . . . . . 2.1 Diagramme de classe (DCL) et diagramme dobjet (DOB) . . . . . . . . . . . . . . 2.1.1 Objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Classe, attribut et opration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IV
UML2 analyse et conception
2.1.3 2.1.4 2.1.5 2.1.6 2.1.7 2.1.8
Association, multiplicit, navigabilit et contraintes . . . . . . . . . . . . . . . . . . Agrgation et composition entre classes . . . . . . . . . . . . . . . . . . . . . . . . . . . Association qualifie, dpendance et classe dinterface . . . . . . . . . . . . . . . . Gnralisation et spcialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Strotype de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exercices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23 27 30 32 36 36 46 46 46 50 50 51 51 52 53 54 54 56 56 58 58 58 61 61 61 63 64 66 67 72 72 73 75 78
2.2 Diagramme de composant (DCP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Composant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Les deux types de reprsentation et exemples . . . . . . . . . . . . . . . . . . . . . . . 2.3 Diagramme de dploiement (DPL). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 Nud. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Artefact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Spcification de dploiement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Liens entre un artefact et les autres lments du diagramme . . . . . . . . . . . . Reprsentation et exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 Diagramme de paquetage (DPA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Paquetage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Dpendance entre paquetages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.3 Reprsentation et exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Diagramme de structure composite (DSC). . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1 Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.2 Reprsentation et exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapitre 3 Les diagrammes comportementaux . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Diagramme des cas dutilisation (DCU). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 3.2.1 3.2.2 3.2.3 3.2.4 Prsentation gnrale et concepts de base . . . . . . . . . . . . . . . . . . . . . . . . . . Reprsentation du diagramme des cas dutilisation . . . . . . . . . . . . . . . . . . . Relations entre cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Description textuelle dun cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prsentation gnrale et concepts de base . . . . . . . . . . . . . . . . . . . . . . . . . . Reprsentation du diagramme dtat-transition dun objet . . . . . . . . . . . . . . Complments sur le diagramme dtat-transition . . . . . . . . . . . . . . . . . . . . Exercices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Diagramme dtat-transition (DET) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tables des matires
3.3 Diagramme dactivit (DAC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Prsentation gnrale et concepts de base . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Reprsentation du diagramme dactivit . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.3 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Diagramme de squence (DSE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 3.4.2 3.4.3 3.4.4 3.4.5 Prsentation gnrale et concepts de base . . . . . . . . . . . . . . . . . . . . . . . . . . Oprations particulires. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fragment dinteraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Autre utilisation du diagramme de squence. . . . . . . . . . . . . . . . . . . . . . . . Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80 80 87 88 90 90 91 93 101 102 104 104 105 106 106 106 108 109 109 109 111 111 112 112 112 112 113 113 113 114 116 117 118 119
3.5 Diagramme de communication (DCO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 Prsentation gnrale et concepts de base . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.2 Formalisme et exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.3 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Diagramme global dinteraction (DGI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.1 Prsentation gnrale et concepts de base . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.2 Reprsentation et exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7 Diagramme de temps (DTP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.1 Prsentation gnrale et concepts de base . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.2 Reprsentation et exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapitre 4 Dmarche de dveloppement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Prsentation dUP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Les principes dUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 4.2.2 4.2.3 4.2.4 Processus guid par les cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . Processus itratif et incrmental. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Processus centr sur larchitecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Processus orient par la rduction des risques . . . . . . . . . . . . . . . . . . . . . . .
4.3 Les concepts et les deux dimensions du processus UP . . . . . . . . . . . . . . . . . . 4.3.1 Dfinition des principaux concepts et schma densemble . . . . . . . . . . . . . . 4.3.2 Phases et itrations du processus (aspect dynamique) . . . . . . . . . . . . . . . . . 4.3.3 Activits du processus (aspect statique) . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Les principaux apports de RUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Les bonnes pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2 Les phases et les activits du processus . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VI
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 5.2.2 5.2.3 5.2.4 laboration du schma de contexte du domaine dtude (FG1). . . . . . . . . . laboration du diagramme dactivit (FG2). . . . . . . . . . . . . . . . . . . . . . . . laboration du diagramme de classe mtier (FG3) . . . . . . . . . . . . . . . . . . . Extrait des documents de cadrage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 150 151 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5.1 laboration du diagramme de classe rcapitulatif (FG13) . . . . . . . . . . . . . 6.5.2 laboration de la matrice de validation (FG14) . . . . . . . . . . . . . . . . . . . . . 6.6 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.1 Ralisation des choix techniques et laboration des diagrammes techniques (FG15, FG16, FG17) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.2 laboration du diagramme de paquetage (FG18). . . . . . . . . . . . . . . . . . . . Annexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A. B. Rcapitulatif des concepts dUML 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rcapitulatif de la dmarche UP7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
202 202 204 204 204 216 219 219 222 223 225
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 pression 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 systmes dinformation. Notons aussi quInternet a t un vecteur favorisant le dveloppement de trs nombreuses applications dont une grande partie utilise des solutions base de langage 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 conception 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].
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 lautomatisation 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 dcennies 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 traduire 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 successives de la norme qui se caractrise aujourdhui par plusieurs centaines de pages lire et un nombre sans cesse croissant de concepts assimiler associs une reprsentation 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 constater 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 normatif 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 projets 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 conception 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 dveloppement 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 pratique des mthodes auprs des quipes de dveloppement de projets ont t particulirement 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 donne 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
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-transition, 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 dinformation. 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 lapprentissage dUML 2 (chapitres 1 3) et ensuite sexercer la mise en pratique grce la dmarche 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 changements 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 dapplications 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.
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 reporter 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 comportement 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 identique (liste des attributs) et un mme comportement (liste des oprations).
1.1 Concepts de lapproche objet
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 entreprise. 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 regroupement 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 multiplicits (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 relation composant-compos ou la relation structurelle reprsentant lorganigramme dune entreprise sont des exemples types de la relation dagrgation.
CLASSE N
Traitements
Accs aux donnes via linterface (partie visible de la classe)
I N T E R F A C E
1- Oprations accessibles - opration 1 - opration 2 - opration 3
Donnes : liste des attributs
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 superclasse, 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 diffremment suivant le contexte de la classe o elle se trouve. Ainsi une opration dfinie dans une super-classe peut sexcuter de manire diffrente selon la sous-classe o elle est hrite.
1.1 Concepts de lapproche objet
En fait lors de lexcution, lappel de lopration va automatiquement dclencher lexcution de lopration de la sous-classe concerne. Dans le droulement de lexcution 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 sousclasses.
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. Oprations : calculSalaire( ). Nom de la sous-classe : NonCadre. Attributs : niveau de spcialisation. Oprations : calculSalaire( ). 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 spcialisation 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 lopration 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 explicitement lopration calculSalaire( ) de la super-classe pour bnficier des traitements communs aux cadres et non cadres et ensuite il y aura poursuite du traitement spcifique 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 dcrivent 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 avantages 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 rutilisation 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 modularit dans la construction dune application laide dobjets, la maintenance lmentaire 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
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 entreprise.
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 reprsente 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 diagrammes les plus structurants dUML des exercices densemble corrigs et nous traitons aussi un exercice de synthse (Locagite) qui nous sert de fil conducteur et dillustration 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 gnraux 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 associes 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 mtamodle 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 description 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 situation 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 ncessaire soit lvolution gnrale dUML, soit la prise en compte de situations particulires propres aux entreprises. Les strotypes peuvent sappliquer nimporte quel concept dUML. Nous nous intresserons dans cet ouvrage un certain nombre dentre eux que nous prsenterons 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 modlisation et en particulier pour les attributs de classe. Une valeur marque se dfinit au niveau mta-attribut.
Formalisme et exemple 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.
10
Note
Une note correspond un commentaire explicatif dun lment dUML.
Formalisme et exemple 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.
Formalisme et exemple
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
possder
Rsident
{le parking dun rsident se trouve dans limmeuble du rsident}
Immeuble rsider
Figure 1.4 Exemple dutilisation dune contrainte (sans reprsentation des multiplicits)
11
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 ensembles. 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 dinstances 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 reprsente un ensemble homogne dlments du systme (classes, composants). 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 diagrammes les plus structurants dans lanalyse dun systme. Diagramme dtat-transition (machine dtat) Ce diagramme montre les diffrents 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.
12
Diagramme de communication (anciennement appel collaboration) Ce diagramme 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 fournit 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 conception dun systme. Ce qui a pour consquence par exemple de ne pas disposer dune vision des interactions entre les diagrammes.
Formalisme et exemple 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 premier niveau de site web dans lequel elle prsente succinctement les formations proposes et enregistre en ligne les demandes de catalogue. Nous pouvons ds ce stade de lanalyse reprsenter le diagramme des cas dutilisation (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 manipuls, savoir : Client, Catalogue et Formation.
13
Client numClient nomClient +crer( ) +consulter( ) commander
Catalogue dateCatalogue +crer( ) +consulter( )
Formation attributs codeFormation intitulFormation descriptionFormation +ajouterFormation( ) +consulterFormation( )
oprations
contenir
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.
14
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 : DCL : DOB : DCP : DCU : DCO : DET : DGI : DPA : DPL : DSC : DSE : DTP : Diagramme dactivit Diagramme de classe Diagramme dobjet Diagramme de composant Diagramme des cas dutilisation Diagramme de communication Diagramme dtat-transition Diagramme global dinteraction Diagramme de paquetage Diagramme de dploiement Diagramme de structure composite Diagramme de squence Diagramme de temps
15
Description du systme
DCU
(interactions acteur/systme)
DSE
ou
DCO
(interactions acteur/objets)
Vues globales ou spcialises
+
DAC
(processus, flots de contrle et de donnes)
DOB
(objets)
DGI
(vue macro de DAC et DSE)
DCL
(classes et associations)
(tats dobjet)
DET
(tats dobjet et temps)
DTP
Architecture technique DCP

(composants techniques)
DSC DPL
(collaboration dlments composites)
(dploiement 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 matrialiss par des oprations. Le dtail des traitements nest pas reprsent directement dans le diagramme de classe ; seul lalgorithme gnral et le pseudo-code correspondant 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 contexte 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 n 12
Client 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 dfinition). 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 programme, 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 Attributs Oprations Responsabilits et/ou exception Description complte Marque Puissance Description rduite la dsignation de la classe Client
Classe rduite deux compartiments
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).
Formalisme et exemple La figure 2.3 montre le formalisme et un exemple de reprsentation des attributs de classe.
Nom de la classe Nom et caractristique attribut 1 Nom et caractristique attribut 2
Voiture Num_immatriculation : texte
Figure 2.3 Formalisme dattributs de classe et exemple
20
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.
Formalisme et exemple 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 Nom et caractristique attributs
Voiture marque : texte rouler (vitesse)
Nom et caractristique opration 1 Nom et caractristique opration 2
Figure 2.4 Formalisme et exemple doprations de classe
21
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 disponibles 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 comportement 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.
22
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 10 CV 2L 2001
audi 10 CV 2L 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 indiqus 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 lintrieur 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.
23
Voiture - marque - puissance - cylindre - anne - chiffreAffaire + dmarrer ( ) - rouler ( ) + freiner ( ) # arrter ( )
Figure 2.8 Exemple de reprsentation des symboles de visibilit
Formalisme et exemple 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 lopration 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 association peut tre identifie par son nom. Une association entre classes reprsente les liens qui existent entre les instances de ces classes.
24
Formalisme et exemple 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 lassociation
Nom de classe B
Personne Possder
Voiture
Figure 2.10 Formalisme et exemple dassociation
Rle dassociation
Le rle tenu par une classe vis--vis dune association peut tre prcis sur lassociation.
Exemple La figure 2.11 donne un exemple de rle dassociation.
Personne nom prnom
Travailler dans
Entreprise nom entreprise adresse
employ
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 multivalu. Le domaine de valeurs est dcrit selon plusieurs formes : Intervalle ferm Exemple : 2, 3 ..15. Valeurs exactes Exemple : 3, 5, 8.
25
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 minimale et maximale dinstances dune classe vis--vis dune instance dune autre classe.
Formalisme et exemple Nous donnons, la figure 2.12, quelques exemples des principales multiplicits dfinies dans UML.
* A 0..1 B une instance de A correspond 0 ou 1 instance de B. une instance de B correspond 0 nombre non dtermin dinstances de A. une instance de A correspond 1 un nombre non dtermin dinstances de B. une instance de B correspond 2 10 instances de A. une instance de A correspond 2 4 instances de B. une instance de B correspond 1 ou 3 instances de A.
2..10 A
1..* B
1, 3 A
2..4 B
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 nonnavigabilit se reprsente par un X Les situations possibles de navigabilit sont reprsentes la figure 2.13.
Navigabilit unidirectionnelle de A vers B. Pas de navigabilit de B vers A
Navigabilit unidirectionnelle de B vers A. Navigabilit de A vers B
Navigabilit bidirectionnelle entre A et B.
Figure 2.13 Reprsentation de la navigabilit dassociation
26
Par dfaut, on admet quune navigabilit non dfinie correspond une navigabilit 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 nom prnom
Copie dexamen 1 produit 1..5 numro copie
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 nom prnom
1..*
Travailler dans
1, 2
{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.
27
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 ( ) * Personne nom prnom * Travailler Mobiliser * 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 . Lagrgation reprsente un lien structurel entre une classe et une ou plusieurs autres classes.
28
Formalisme et exemple 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 U.C.
1 Clavier
1 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 . Autrement dit la suppression de la classe compos implique la suppression de la ou des classes composant . Formalisme et exemple 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.
29
Classe 1 Classe compos
Classe 2 Classe composant
Figure 2.19 Formalisme de la composition
Commande
1 En-tte
1..* Lignes commandes
Figure 2.20 Exemple dune relation de composition
Commande
En-tte
Lignes commandes 1..*
Figure 2.21 Exemple de la seconde forme de reprsentation de la relation de composition
30
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 concernes par lassociation. Cet attribut ne fait pas partie de lassociation.
Formalisme et exemple 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.
Fichier *
Rpertoire
contenir
1 Rpertoire nom de fichier
1 Fichier
Figure 2.22 Formalisme et exemple dassociation qualifie
Dpendance
La dpendance entre deux classes permet de reprsenter lexistence dun lien smantique. Une classe B est en dpendance de la classe A si des lments de la classe A sont ncessaires pour construire la classe B.
Formalisme et exemple 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
31
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 associ la classe source. La classe utilisatrice de linterface est relie au symbole de linterface par une flche en pointill. La classe dinterface est une spcification et non une classe relle. Une classe dinterface peut sassimiler une classe abstraite.
Formalisme et exemple La figure 2.24 donne le formalisme, sur un exemple, des deux types de reprsentation dune interface.
Fentre code 1* dlacer ( ) ouvrir ( ) fermer ( ) utilise ralise Indique que la classe Fentre ralise linterface Autorisation interface Autorisation Indique que la classe Mot de passe utilise linterface Autorisation Donner accs 1 contrler ( ) Mot de passe numro
ouvrir ( )
Autorisation Fentre code 1* dlacer ( ) ouvrir ( ) fermer ( )
Indique que la classe Mot de passe utilise une interface de la classe Fentre appele Autorisation Mot de passe numro
Donner accs
1 contrler ( )
Figure 2.24 Exemple de description dune classe dinterface
32
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 partageant 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 sousclasses partir dune classe.
Formalisme et exemple 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 (hritage) Gnralisation
Sous-classe A1
Sous-classe 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.
33
La figure 2.26 montre un exemple de relation de spcialisation. Dans cet exemple, 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 taux horaire taux horaire supplmentaire calculer paie ( )
Employ salari taux hebdomadaire
Vacataire taux journalier
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 ;
34
{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 dindiquer seulementdes points de suspension ().
Formalisme et exemple 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 {chevauchement}
Employ
1..* tre inscrit 1 Universit Travailler
1..* 1 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.
Formalisme et exemple 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 .
35
Classe A nom prnom ge
Classe A1 nom prnom ge sexe
Classe A2 extension restriction crer ( ) nom ge
crer ( )
Figure 2.28 Exemple dhritage avec extension et restriction de proprits

Vhicule
Vhicule terrestre
Vhicule marin
Auto
Vhicule amphibie
Bateau
Figure 2.29 Exemple de relation dhritage multiple
36
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 classes 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 spcialisation 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 sousensemble 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 rgionale est caractrise par un code et un libell.
37
Objet graphique Document nom ouvrir ( ) fermer ( ) 1..* Feuillet nom ouvrir ( ) fermer ( ) 1..* nom copier ( ) coller ( ) couper ( ) dplacer ( )
Objet gomtrique
Texte nom
Rond centre rayon dessiner ( )
Ligne x y dessiner ( ) 4 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 matrialise une relation structurante entre ces classes. La relation entre Agence et Personnel est une association de un plusieurs. Les oprations mentionnes dans chaque classe correspondent aux oprations lmentaires ncessaires la gestion du personnel des agences.
38
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 consulter ( ) demander-crer-agence ( ) demander-supprimer-agence ( )
1 DIAGRAMME DE CLASSE DE L'EXERCICE 2
comprendre
1..*
Personnel code : nombre date arrive agence : DATE numro : nombre qualit : texte nom : texte prnom : texte date naissance : DATE date prvisionnelle arrive : DATE date arrive agence : DATE date dpart agence : DATE
1..*
Agence code : nombre intitul : texte date cration : DATE date fermeture : DATE crer ( ) supprimer ( ) modifier ( ) visualiser ( ) imprimer ( ) rattacher_personnel ( ) dtacher_personnel ( )
appartenir
1
crer ( ) supprimer ( ) rechercher ( ) imprimer ( ) modifier ( ) rattacher lagence ( )
Dir-rg-Alsace 15 Alsace EXEMPLE DE DIAGRAMME DOBJET
comprendre
Ag-Strasbourg : Agence : personnel 671 Strasbourg 15/01/98 appartenir
Figure 2.32 Exemple de diagramme dobjet associ au diagramme de classe de lexercice 2
39
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 prvisionnelles 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 Date catalogue Date session Dure cours tat de la session (prvue, annule, en cours, close) Intitul du cours Lieu session Matricule N catalogue N document N session Nom Organisme extrieur Prnom Service 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 enseignante) et PersonneIntEn (enseignante). Le diagramme de classes peut tre labor ensuite sans difficult. La figure 2.33 donne le corrig type de cet exercice.
40
Document habiliter animer -n document -titre document +crer ( ) 0..* Session 0..* PersExt PersIntNEns -service +enseigner ( ) 0..* 1 +inscrire ( ) +enseigner ( ) 0..* inscrire diriger PersIntEns -service -n session-cours -date session -tat -lieu 1..* +crer ( ) +annuler ( ) +commencer ( ) +clore ( ) 0..* +convoquer ( ) 0..* 1..* utiliser 0..* 0..* Cours 1 -code cours se drouler -intitul -dure +crer ( ) 0..* ncessiter 0..*
Personne -matricule -nom -prnom +crer ( )
Catalogue Organisme 1 rattacher -organisme +crer ( ) 1 -n catalogue -date +crer ( )
Exercice 4 nonc Il vous est demand de grer les apports de raisin de la cooprative viticole de champagne. Le processus de traitements des apports de raisin correspond un droulement en plusieurs tapes.
Dpart des camions pour le ramassage des raisins Le ramassage est organis 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 darrive 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 responsable de la pese puis enregistrs.
41
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 provenance 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 cooprateur, le pourcentage de sa production quil apporte la cooprative est enregistr. 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 statut juridique quils ont choisi. Celui-ci est identifi par le code du statut et se caractrise 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 de palette 428 102 14 123 Nombre de caisses 8 14 10 12 Poids net en kg 459 642 670 578
42
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 -ncamion -nbMaxiPalette 1 * -napport -poidsVide -nitinraire -dateArrive -dateDpart 1 concerner 1 Livreur rpartir * Lot -nLot * Palette 0..* appartenir 1 Indpendant Cepage * choisir 1 Statut -codeStatut -libelleStatut Classement -nClassement 0..* Anne 0..* classer -codeCepage 0..* -nPalette * peser
Pese -nbCamions -poids
correspondre 1 Commune -nInsee -nomCommune
Cooprative -%Production 1 exploiter * Parcelle -nParcelle
43
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 rmunration 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 centrale 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 disponibles 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.
44
Tableau 2.3 Principales informations portes par les documents changs Catalogue Anne du catalogue N du gte Nom de la commune Adresse du gte Animaux accepts (O, N) NB dtoiles NB de personnes acceptes Contrat propritaire N de contrat propritaire N propritaire Nom du propritaire Adresse et tl. du propritaire Rfrence du gte Description du gte (voir ci-dessus) Tarifs semaine (HS, juin/sept/Vac Scol) Priodes de location Capacit (nb. de chambres) Description du gte (texte) Adresse et tl. du propritaire (pour la rservation) ou tl. du service de rservation Tarifs semaine (HS, juin/sept/Vac Scol) Activits disponibles et distance (ex. : piscine 3 km) tat mensuel des locations N propritaire, nom du propritaire, adresse et tl. du propritaire Par contrat, par gte et par rservation : N de rservation Date darrive Date de dpart NB de nuits Nom et adresse du locataire NB dadultes NB denfants Animaux (O, N) Montant reu, Montant recevoir
Contrat de location N du contrat Rfrence du gte Nom du propritaire Ville ou village ou se situe le gte Dates darrive et de dpart Prix du sjour : 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 Composition de la famille Nom Adresse NB adultes NB denfants Animaux domestiques (O, N) Tlphone
Gte Activit -codeActivit -libellAct -distance * 1..*
Catalogues avoir
-anne paratre 1..* appartenir 1..* 1 +modifNbtoile() Gte gr mettre en location 1..* PriodeLocation Rservation 1 0..* concerner correspondre 1 0..1 -priode -tarif +recherchePriode() rserver 1 1..* +rechercheGite() -ncontratProp -tauxRnum +modifNcontratP() +tatRservation() +crationGite()
1..*
+ajoutGite()
Propritaire
-nPropritaire -adresse -tel
-nGite -commune -adresse -animalAccept -description -capacit -nbEtoile -nbPersAccept +majActivit() +modifActivit() +afficheActivit()
Gte non gr
+crationPropritaire() +contrlePropritaire()
Figure 2.35 Diagramme de classe de Locagite
Personnes
Contrat Location -nContratLocation -mtRecu -mtArecevoir +crationContrat() +majMt() +destructionContrat()
Client
-nPersonne -nom -prnom -adresse -tel
-nLocataire
+crationClient() +contrleClient()
-nRservation -dateArrive -dateDpart -nbNuit -nbAdulte -nbEnfant -animaux -mtRecu -mtArecevoir +crationRservation() +rechercheRservation() +dtruireRservation()
Figure 2.35 Diagramme de classe de Locagite 45
46
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 caractris par : un nom ; une spcification externe sous forme soit dune ou plusieurs interfaces requises1, 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 interfaces 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 composant 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
48
Compartiment Une dernire manire de modliser un composant avec une reprsentation bote noire est de dcrire sous forme textuelle les interfaces fournies et requises lintrieur 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 classificateurs (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 compartiment, les artefacts (lment logiciel : jar, war, ear, dll) qui reprsentent physiquement 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 reprsentes 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 Commande est donn la figure 2.42.
Figure 2.42 Reprsentation bote blanche avec connecteurs
50
Dans lexemple de la figure 2.42, le composant Commande est constitu de deux classes (classificateur) relies par une agrgation : DetailCommande et LigneCommande. Linterface fournie GestionCommande est accessible de lextrieur via un port et permet daccder via les connecteurs aux oprations des deux classes DetailCommande et LigneCommande (ajouterLigneCommande, calculTotal-Commande, calculPrixLigne). Linterface requise Personne est ncessaire pour laffichage du dtail de la commande 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 supportant lexploitation du systme. Cette architecture comprend des nuds correspondant aux supports physiques (serveurs, routeurs) ainsi que la rpartition des artefacts logiciels (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 artefacts 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 application
serveur J2EE
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 motcl 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.
Formalisme et exemple Une spcification de dploiement se reprsente par un rectangle avec le mot-cl deployment spec . Un exemple dun artefact avec une spcification de dploiement est donn la figure 2.45.
52
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 reprsent lintrieur du nud auquel il se situe physiquement. Un exemple est donn la figure 2.46.
CommandeServeur1
<<artifact>> PriseCom.jar
<<artifact>> 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>> PriseCom.jar
<<artifact>> 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 qualificatif 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 dploiement dfinies. Un premier exemple est donn la figure 2.48.
CommandeServeur1 <<artifact>> facture.jar <<artifact>> PriseCom.jar
"deployment spec" PriseComdescr.xml
"deployment spec" 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 composants ncessaires au fonctionnement de cette archive web comme clientejb.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 archives sont ncessaires au fonctionnement des EJB : dao.jar (classes qui permettent laccs la base de donnes) et commun.jar (classes communes aux deux serveurs dapplication). Un serveur BDD (base de donnes) sur lequel sont stockes des procdures stockes PL/SQL : scripts.sql .
54
<<device>> Serveur web <<artifact>> static.zip
<<device>> Serveur application front <<artifact>> front.ear
<<artifact>> front.war
<<artifact>> client-ejb.jar
<<artifact>> commun.jar
<<device>> Serveur application mtier <<artifact>> metier.ear
<<artifact>> ejb.jar
<<artifact>> commun.jar
<<artifact>> 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
Nom du paquetage
Membre A
Membre B
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
56
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 paquetages 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 visibilit 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
Rservation
Location
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 paquetage contenant la fusion des deux paquetages dorigine. Pour bien clarifier cette opration, 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
merge
fusion
devenir
B B Paquetage dorigine Paquetage rsultat
Figure 2.54 Exemple de liens de fusion entre paquetages
58
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.
ClasseMtier
Persistance objets mtier
TableBDD
attribut1 attribut1 attribut2 attribut2
mapping
stockage
attribut1 attribut1 attribut2 attribut2
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 collaboration 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 participantes qui sont considrs suivant les rles pris en compte.
3
Les diagrammes comportementaux
Les diagrammes comportementaux sont focaliss sur la description de la partie dynamique 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.
Formalisme et exemple Un acteur peut se reprsenter symboliquement par un bonhomme et tre identifi 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 dutilisation.
3.1 Diagramme des cas dutilisation (DCU)
63
Formalisme et exemple 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 identifier 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 correspondant 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 ensemble de cas dutilisation qui correspond aux besoins des acteurs de ce systme.
64
Systme de messagerie 1
* 1
Connexion
Acteur A
1 1
*
Lecture bote
*
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 rutilisation 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.
Formalisme et exemple La figure 3.4 donne le formalisme et un exemple dune relation dinclusion entre cas dutilisation.
65
Cas A include
Cas B include Cas C Les cas A et C ont recours au cas B
Cration dun nouvel abonn
include
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.
Formalisme et exemple 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.
Formalisme et exemple La figure 3.6 donne un exemple dune relation de gnralisation de cas dutilisation.
66
extend Cas B
Cas A Point d'extension : X
Servir boisson chaude Point dextension : X Condition : {si plus de sucre} Point dextension : X
Client extend
Servir supplment sucre
Figure 3.5 Formalisme et exemple dune relation dextension entre cas dutilisation
*
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 interactions 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. Cependant, les travaux mens par Alistair Cockburn [Cockburn2001] sur ce sujet constituent une rfrence en la matire et tout naturellement nous reprenons ici lessentiel de cette prsentation.
67
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 identifis 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) rappelant 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 bibliothcaires 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 seulement sacquitter dune somme forfaitaire pour une anne afin davoir droit tous les services de la bibliothque. Laccs la bibliothque est libre pour tous les enseignants. Enfin, il est possible dautoriser des tudiants dune autre universit sinscrire 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 exceptionnellement cinq semaines. Il est demand dlaborer le diagramme des cas dutilisation (DCU).
68
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
69
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.
70
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 : Le systme raffiche le formulaire de saisie en indiquant les erreurs dtectes. Le coordonnateur corrige les erreurs. Le cas dutilisation reprend laction 2 du scnario nominal.
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 <<include>> 3.2 Authentification client <<extend>> 4.2 Gestion annulation Gestionnaire rservation
<<extend>> <<include>> 4.1 Gestion location Client locataire
Figure 3.8 Diagramme des cas dutilisation de Locagite
71
Scnario 1.1.2 Modification gte Objectif Permettre la modification dun gte dj prsent dans le catalogue. Acteurs concerns Gestionnaire catalogue. Pr conditions Aucune. 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,
Scnarios alternatifs 1-a : Erreur de saisie du gte : Le systme raffiche le formulaire de saisie en indiquant lerreur dtecte. Le coordonnateur corrige les erreurs. Le cas dutilisation reprend laction 1 du scnario nominal. 2-a : Erreurs de 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 2 du scnario nominal.
Cas dutilisation 1.2 : Publication du catalogue Ce cas dutilisation ne comporte quun seul scnario.
Scnario Publication du catalogue Objectif Permettre ldition du catalogue. Acteurs concerns Gestionnaire catalogue. Pr conditions Aucune. 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. Acteurs concerns Gestionnaire catalogue. Pr conditions Aucune. Scnario nominal : 1. Saisir le code propritaire, le code du gte et le nombre dtoile. 2. Mettre jour le nombre dtoile.
72
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. Le cas dutilisation reprend laction 1 du scnario nominal.
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 traiterons 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).
Formalisme et exemple Un objet reste dans un tat pendant une certaine dure. La dure dun tat correspond 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.
tat 1
vnement [condition]
tat 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
Employ recrut
Prise de fonction [date d'embauche chue] Employ 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.
Formalisme et exemple Le formalisme de reprsentation dtat-transition comprenant la reprsentation daction et/ou activit est donn la figure 3.11.
tat 1 Faire activit 1
vnement [condition]/action
tat 2 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 description complte dune transition.
tat 1 faire : travaille
Maladie [avec arrt]/mise en arrt
tat 2 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.
74
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 initial
tat 2
tat 3
tat 4 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 dtattransition de lobjet client.
Passer 1 commande Client prospect Client actif Paiement Client en contentieux
re
Non-paiement Client douteux
Limite financire dpasse
Ne passe plus commande
Client inactif Une anne sans commande
Client supprim Fin du contentieux
Figure 3.14 Diagramme dtat-transition de lobjet client dune gestion commerciale
Nous proposons comme second exemple, la figure 3.15, le diagramme dtattransition 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 renseigne.
75
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.
Formalisme et exemple Le formalisme de reprsentation dtats composites est donn la figure 3.16.
enregistr/contrler Reu Contrl contrl/dcider Accept
Symbole de reprsentation dun tat composite Dtail de ltat composite
contrler feuille
contrle nSS
contrle des droits
Figure 3.16 Exemple dtat composite
76
Dans cet exemple, ltat contrl est un tat composite qui fait lobjet dune description 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.
Formalisme et exemple Le formalisme de reprsentation dune sous-machine dtat avec point dentre et de sortie est donn la figure 3.17.
Sortie standard
tat aval
tat amont Entre standard
Sous-machine d'tat Anomalie
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.
Formalisme et exemple 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.
Formalisme et exemple Le formalisme de reprsentation dtats composites est donn la figure 3.19.
77
Point de jonction
message vocal reu [typeMessage = vocal]
A/R message vocal
message SMS reu
[typeMessage = SMS]
A/R message SMS
[typeMessage = Fax] message Fax reu A/R message Fax
Figure 3.18 Exemple dtats-transitions avec point de jonction
Point de choix
message vocal reu
message mobile reu/activerA/R
A/R mobile
message SMS reu
message mobile reu/activerA/R
[typeMobile]
[else] message Fax reu

message Fax reu/activerA/R
A/R Fax
Figure 3.19 Exemple dtats-transitions avec point de choix
78
tat historique
La mention de lhistorisation dun tat composite permet de pouvoir indiquer la rutilisation du dernier tat historis en cas de besoin.
Formalisme et exemple 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, activit, en cong, en arrt, parti et retraite.
79
retraite
Demande de retraite [ge]/mise en retraite Arrive/prise de fonction recrut Maladie/mise en maladie
activit Reprise/reprise activit
en arrt
Dmission/dpart
Retour 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.
80
annulation sjour
cration Gte louer
rservation
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 oprations 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 diagramme 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.
Formalisme et exemple 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.
Formalisme et exemple Le formalisme de reprsentation dune transition est donn la figure 3.24.
action 1 transition action 2
Figure 3.24 Formalisme de base du diagramme dactivit : actions et transition
82
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 bifurcation, 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.
Formalisme et exemple Nous donnons une premire reprsentation simple la figure 3.25.
activit : Traiter commande
Saisir commande
Contrler commande
diter 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.
Formalisme et exemple 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.
83
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 entretien technique
Prparation 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 concurrents en entre de la synchronisation, de produire un flot unique sortant. Le nud de jonction est le symtrique du nud de bifurcation.
Formalisme et exemple Le formalisme de reprsentation dun nud de jonction est donn la figure 3.28.
84
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.
Formalisme et exemple 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-dcision 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
85
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. Formalisme et exemple 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 par messagerie
Facturer
Commander par courrier
Figure 3.31 Formalisme et exemple de diagramme dactivits avec un nud de fusion-test
86
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. Formalisme et exemple 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 utilisant le pin dobjet soit en reprsentant explicitement un objet. Formalisme et exemple Le formalisme de reprsentation de flot de donnes et nud dobjet est donn directement 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
87
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 couloirs 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 interactions de communication lies certains types dvnement peuvent se reprsenter. Les types dvnement concerns sont : signal, coulement du temps.
88
Formalisme et exemple 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 adhrents ayant dpass le dlai de restitution des ouvrages. La reprsentation du diagramme dactivit est donne la figure 3.36.
89
Gestionnaire
Bibliothcaire
inscrire adhrent
acqurir ouvrage
[ouvrage] [adhrent]
mettre jour catalogue
enregistrer emprunt/retour
[ si pas adhrent ] contrler dpassement dlai
[ anomalies ]
[ 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.
90
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 dinformation 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.
Formalisme et exemple 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.
92
sd Diagramme 1 objet1
objet2
objet3
: Client message 1()
Ligne de vie
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 simplement 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.
93
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 fragment. 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.
Formalisme et exemple 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.
94
sd Diagramme densemble
Interface IHM : Gestionnaire saisirCommande( ) contrlerClient( )
Client
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 alternatives possibles. Il est aussi permis dutiliser les clauses de type sinon.
Formalisme et exemple Loprateur alt se reprsente dans un fragment possdant au moins deux parties spares 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).
Formalisme et exemple 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 boucle 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.
95
: Adhrent : Gestionnaire saisirAdhrent( ) contrlertat( )
: Emprunt
alt tatEmprunt [tat emprunt=rendu] autoriserEmprunt( ) [tat emprunt=non rendu] refuserEmprunt( )
Figure 3.43 Exemple de fragment dinteraction avec loprateur alt
: Adhrent : Gestionnaire relancer( ) testerArelancer( )
: Emprunt
retourSituationRelance opt Relancer [si relance] relancer( )
Figure 3.44 Exemple de fragment dinteraction avec loprateur opt
Formalisme et exemple Loprateur loop se reprsente dans un fragment possdant une seule partie et englobant toutes les interactions faisant partie de la boucle. Un exemple est donn la figure 3.45.
96
: 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.
Formalisme et exemple 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
97
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.
Formalisme et exemple 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 dinteraction 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.
Formalisme et exemple 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( ).
98
sd Exemple break
: Classe1
: Classe2 Op1( ) Op2( )
: Classe3
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 obligatoirement 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.
Formalisme et exemple Lexemple prsent figure 3.50 montre que les oprations Op1( ), Op2( ) et Op3( ) du fragment critical doivent sexcuter sans interruption.
99
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
: Classe1
: Classe2
: Classe3
critical Op1( ) Op2( )
Op3( )
Figure 3.50 Exemple de fragment dinteraction avec loprateur critical
100
Oprateur negative
Loprateur neg (negative) permet dindiquer quune squence dinteractions est invalide.
Formalisme et exemple Lexemple prsent figure 3.51 montre que les oprations Op1( ) et Op2( ) du fragment neg sont invalides. Une erreur sera dclenche dans ce cas lexcution du fragment.
sd Exemple oprateur negative : Classe1 : Classe2 : Classe3
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.
Formalisme et exemple 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.
Formalisme et exemple Lexemple prsent figure. 3.53 montre que lon fait appel un fragment Contrle des droits qui est dcrit par ailleurs.
101
: Classe1 sd Exemple oprateur assert assert Op1( )
: Classe2
: Classe3
Op2( )
Op3( )
Figure 3.52 Exemple de fragment dinteraction avec loprateur assert
sd Gestion des contrats : Classe1 : Gestionnaire saisieIdcontrat( ) : Classe2
: Classe3
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 dutilisation. 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.
102
Scnario A Client X
Reprsentant
Commande
Facture
Demande
Disponibilit articles Rponse disponibilit
Proposition 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
103
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>> IHM : Gestionnaire catalogue crationGte( ) opt Cration propritaire crationPropritaire( )
Propritaire
Gte
Catalogue
Activit
<<create>>
si propritaire 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
104
<<boundary>> IHM : Gestionnaire catalogue propritaire demandelaborationCatalogue( )
Catalogue
Gte
Propritaire
Priode location
Activit
loop Traitement gte afficheCatalogue( ) afficheGte( ) affichePropritaire( ) pour tous les gtes
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 interactions que celle du diagramme de squence. En effet, le diagramme de communication 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 satisfaire.
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
106
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 4 : Agence cre agence :unit Agence
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 interactions 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 (oprateur ref). Autrement dit, le diagramme global dinteraction est un diagramme dactivit dans lequel on reprsente des fragments dinteraction ou des utilisations dinteractions. 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 commander( )
Commande
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
108
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 changements 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 comportement de lobjet ligne par ligne (une ligne pour un tat). tats linaires Il sagit du mme concept que le prcdent, mais la reprsentation 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 chambre 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.
110
La figure 3.64 donne la reprsentation du diagramme de temps en utilisant le formalisme des tats en escalier et la figure 3.65 fournit la reprsentation linaire des tats.
sd Chauffage vapeur
Vapeur demande et rserve eau insuffisante Rserve eau suffisante
:pompe eau :chauffage eau
activ dsactiv activ dsactiv

{ t..t +3}
timer
Figure 3.64 Exemple de diagramme de temps avec reprsentation en escalier
sd Chauffage vapeur
Vapeur demande et rserve eau insuffisante
:pompe eau
Rserve eau suffisante
dsactiv
activ
dsactiv
:chauffage eau
dsactiv
activ
{ t..t +3}
dsactiv
timer
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 gnrale en dcrivant larchitecture deux dimensions dUP et ses principaux concepts, nous passerons aussi en revue les diffrentes phases dUP, et pour finir nous dtaillerons 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 constituent 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 itrations 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.
114
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 itration ou un diagramme produit dans une activit.
Ressources Paul Pierre Architecte Concevoir lapplication Rdiger le dossier darchitecture Rles Chef de projet Anticiper les risques Activits
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 dactivits 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 dopportunit 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 maquettes 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 retrouvent dans le diagramme des cas dutilisation qui est ainsi complt. Cette phase a aussi pour but danalyser le domaine technique du systme dvelopper afin daboutir une architecture stable. Ainsi, toutes les exigences non recenses dans les cas dutilisation, comme par exemple les exigences de performances du systme, seront prises en compte dans la conception et llaboration de larchitecture. 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.
116
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 prcdente le sont ici. Au cours de cette phase, la gestion et le contrle des ressources ainsi que loptimisation 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 dveloppement 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 modlisation 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 lexpression 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 dutilisation, 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 nonrgression. Aprs cette prsentation dUP et afin dclairer le lecteur sur les principaux processus 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 principal de faire appliquer les bonnes pratiques de dveloppement aux entreprises, ce qui confre au produit final une meilleure qualit.
118
RUP se veut tre un modle volutif qui doit tre configur pour pouvoir tre utilis 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 ambigut. 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).
119
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 changements 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 7 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
120
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 Capacit oprationnelle initiale
LCO Objectifs du cycle de vie
LCA Architecture du cycle de vie
PR Livraison du produit
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 principales 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.
121
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 dveloppeurs 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 dutilisation).
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.
122
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 configuration. Grer les configurations de ces lments au cours du processus de dveloppement 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 changement. La gestion de configuration est ralise tout au long du projet. La gestion du changement 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 fournit 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 dcision 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 exprience tire de la ralisation en entreprise de projets avec UML. La dmarche que nous proposons est articule suivant deux axes : les quatre phases 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 ACTIVITS 1- Modlisation mtier
Lancement
laboration
Construction
Transition
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 dutilisation), 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.
124
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 graphiquement. 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 comptence 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 conclure 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 informations 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.
125
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 hommemachine (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 validation. 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.
126
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 technique). Les classes techniques par cas dutilisation (diagrammes de classe technique). Le regroupement sous forme de paquetage de lensemble des classes techniques en un seul diagramme (diagramme de paquetage). De ce fait la conception prliminaire est couverte par cette activit. La conception dtaille qui est la traduction des scnarios et classes techniques dans les solutions 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 associe une fiche guide qui est ensuite dtaille.
127
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
128
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 Sous-activit 1.1 : laboration du schma de contexte du domaine dtude Objectif Point de dpart Point darrive Projet : Date :
Positionner le systme tudier au sein des processus de lentreprise. Esquisse fonctionnelle du besoin exprim. 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.
129
FICHE GUIDE FG2 Activit 1 : Modlisation mtier Sous-activit 1.2 : laboration du diagramme dactivit Objectif Point de dpart Dcrire les processus mtiers du systme tudier. Systme tudier positionn par rapport aux processus de lentreprise et primtre fonctionnel dfini. 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). Projet : Date :
Point darrive
130
FICHE GUIDE FG3 Activit 1 : Modlisation mtier Sous-activit 1.3 : laboration du diagramme de classe mtier Objectif Point de dpart Projet : Date :
Dfinir les concepts mtiers du domaine sous forme de classe. Acteurs identifis et processus mtiers du systme tudi dfinis (flot de contrle, flot de donnes). Concepts mtiers identifis dfinis dans le DCL mtier et le glossaire mtier. Dmarche dlaboration
Point darrive
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.
131
Exigences fonctionnelles
FICHE GUIDE FG4 Activit 2 : Exigences fonctionnelles Sous-activit 2.1 : laboration du diagramme des cas dutilisation systme Objectif Projet : Date :
Recueillir et dcrire les besoins mtiers des acteurs du systme (bote noire). Concepts mtiers identifis et dfinis dans le DCL mtier et le glossaire mtier. Besoins mtiers recueillis sous la forme de cas dutilisation (DCU systme) et dcrits de manire gnrale. DMARCHE DLABORATION
Point de dpart
Point darrive
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.
132
FICHE GUIDE FG5 Activit 2 : Exigences fonctionnelles Sous-activit 2.2 : laboration des diagrammes de squence systme Objectif Projet : Date :
Dfinir les interactions entre les acteurs mtiers et le systme (bote noire) pour tous les cas dutilisation mtiers. Besoins mtiers recueillis sous la forme de cas dutilisation et dcrits de manire gnrale. Interactions entre acteurs mtiers et systme dfinis dans le DSE. Dmarche dlaboration
Point de dpart
Point darrive
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.
133
FICHE GUIDE FG6 Activit 2 : Exigences fonctionnelles Sous-activit 2.3 : laboration du schma de navigation gnrale Objectif Point de dpart Dterminer la cinmatique des crans du systme. Interactions entre acteurs et systme dfinies pour les cas dutilisation mtiers. 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. Projet : Date :
Point darrive
134
Analyse des cas dutilisation

FICHE GUIDE FG7 Activit 3 : Analyse des cas dutilisation Sous-activit 3.1 : laboration du diagramme des cas dutilisation Objectif Projet : Date :
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). Besoins mtiers, interactions acteurs mtiers/systme, IHM dfinies. Tous les cas dutilisation dfinis dans le DCU. Dmarche dlaboration
Point de dpart Point darrive
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.
135
FICHE GUIDE FG8 Activit 3 : Analyse des cas dutilisation Sous-activit 3.2 : Description des cas dutilisation Objectif Point de dpart Point darrive Projet : Date :
Dcrire de manire textuelle et dtaille les cas dutilisation. Tous les cas dutilisation dfinis. Cas dutilisation dcrits de manire textuelle. Dmarche dlaboration
Pour chaque cas dutilisation (CU) : 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 .
136
FICHE GUIDE FG9 Activit 3 : Analyse des cas dutilisation Sous-activit 3.3 : laboration des diagrammes de squence Objectif Projet : Date :
Reprsenter les interactions entre les acteurs et les objets du systme pour tous les cas dutilisation en considrant les diffrents scnarios dcrits. Cas dutilisation dcrits de manire textuelle et concepts mtiers identifis et dfinis. Interactions entre acteurs et objets du systme dcrits dans le DSE pour tous les cas dutilisation. Dmarche dlaboration
Point de dpart
Point darrive
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.
137
FICHE GUIDE FG10 Activit 3 : Analyse des cas dutilisation Sous-activit 3.4 : laboration des diagrammes dtat-transition Objectif Projet : Date :
Dfinir dune part les tats des objets significatifs du systme tudi et dautre part les actions associes aux transitions. Cas dutilisation dcrits de manire textuelle et concepts mtiers identifis et dfinis. Les diffrents tats des objets et les transitions entre objets reprsents dans le DET. Dmarche dlaboration
Point de dpart
Point darrive
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).
138
FICHE GUIDE FG11 Activit 3 : Analyse des cas dutilisation Sous-activit 3.5 : laboration des interfaces utilisateur Objectif Projet : Date :
Modliser les interfaces utilisateur de tous les cas dutilisation pour donner une vue concrte de lapplication aux utilisateurs. Cas dutilisation dcrits de manire textuelle et interactions entre acteurs et objets du systme dfinies pour tous les cas dutilisation. Interfaces utilisateur dfinies pour tous les cas dutilisation. Dmarche dlaboration
Point de dpart
Point darrive
Pour chaque cas dutilisation (CU) : 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.
139
FICHE GUIDE FG12 Activit 3 : Analyse des cas dutilisation Sous-activit 3.6 : laboration des diagrammes de classe Objectif Point de dpart Dfinir les classes pour chaque cas dutilisation. Interactions entre acteurs et objets du systme dfinies pour tous les cas dutilisation et concepts mtiers dfinis dans la modlisation mtier. Classes et associations dfinies pour chaque cas dutilisation dans les DCL par cas dutilisation. Dmarche dlaboration Pour chaque cas dutilisation (CU) : 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. 4 Dterminer les relations entre les classes : 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. Projet : Date :
Point darrive
140
Synthse de lanalyse
FICHE GUIDE FG13 Activit 4 : Synthse de lanalyse Sous-activit 4.1 : laboration du diagramme de classe rcapitulatif Objectif Projet : Date :
Regrouper lensemble des classes dans un seul diagramme pour avoir une vision globale du systme tudi. Tous les diagrammes de classe des cas dutilisation tudis. 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.
141
FICHE GUIDE FG14 Activit 4 : Synthse de lanalyse Sous-activit 4.2 : laboration de la matrice de validation Objectif Projet : Date :
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). Les CU mtiers et danalyse. 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.
142
Conception
FICHE GUIDE FG15 Activit 5 : Conception Sous-activit 5.1 : Ralisation des choix techniques Objectif Point de dpart Projet : Date :
Choisir larchitecture technique cible et les technologies associes. tapes dexpression des besoins et danalyse termines (Activits 1, 2, 3, 4). Architecture technique et technologies associes choisies. Dmarche dlaboration
Point darrive
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 sousactivit. 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.
143
FICHE GUIDE FG16 Activit 5 : Conception Sous-activit 5.2 : laboration des diagrammes de squence technique Objectif Projet : Date :
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.
Architecture choisie, DSE et DCL de lactivit 3. 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.
144
FICHE GUIDE FG17 Activit 5 : Conception Sous-activit 5.3 : laboration des diagrammes de classe techniques Objectif Projet : Date :
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). 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. Toutes les classes (incluant les classes techniques) et associations dfinies pour tous les cas dutilisation. Dmarche dlaboration
Point de dpart
Point darrive
Pour chaque cas dutilisation (CU) : 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. 4 Dterminer les relations entre les classes : 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.
145
FICHE GUIDE FG18 Activit 5 : Conception Sous-activit 5.4 : laboration du diagramme de paquetage Objectif Projet : Date :
Regrouper lensemble des classes en paquetage pour avoir une vision globale et structure du systme tudi. Tous les diagrammes de classe par cas dutilisation. 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.
146
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 classes 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 (ntiers). 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 diffrentes 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
147
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 afficher. 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 architectures 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 fonctionnalits restreintes et permettent de rduire les changes entre les couches.
148
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 lutilisateur 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 coordination, 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 dclenches 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 financiers. 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 propositions 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 propositions 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
[Demande exprime]
[Cadrage saisi]
Instruire
[Demande instruite]
[Attribution propose]
Consolider proposition
[Cadrage ajust]
[Attribution consolide]
Allouer moyens
Arbitrer
Recevoir attributions
[Attribution alloue]
[Attribution arbitre]
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 directeur 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.
152
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 -gradeA -nombreA Attribution-RF +typeMoyenA +montantA Attributions -numAttrib -dateAttrib allouer 1..* 1 Cadrage-DS TypeMoyen
cadrer -typemoyen -DStypeMoyenC 1 1..* -intitulTypemoyen -cadrageA -date arbitrage 1..* fixer 1
Demande -numDemande -dateDemande
Demande-RH -gradeD -nombreD -justificationD-RH
0..* DS Unit correspondre -codeDS 0..1 -code unit rattacher 1 -intitulDS 1..* -intitul unit mettre -nom directeur 1..* 1 -adresse rue allouer-histoRH Histo-attribution-RH -adresse ville 1 -adresse code postal -numAttribHA-RH 1..* 1 allouer-histoRF -dateAttribHA-RH -gradeHA-RH 1 1 -nombreHA-RH Demande-RF
-typeMoyensD demander-histoRH -montantD 1..* -justificationD-RF demander-histoRF Histo-attribution-RF 1..* 1..* 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 scientifiques Ressources humaines (RH) Chercheurs Chimie Physique Sciences de la vie 12 8 22 Ingnieurs 15 7 25 Ressources financires (RF) en k Budget de fonctionnement 21 000 12 000 63 000 Budget dquipement 4 000 3 000 11 000
5.3 Exigences fonctionnelles
153
Demande de moyens des units pour lanne n Dpartements Chimie Ressources humaines (RH) Chercheurs Unit 1 Unit 2 Unit 3 2 1 1 Ingnieurs 3 2 2 Ressources financires (RF) en k Budget de fonctionnement 1 000 800 900 Budget dquipement 500 200 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.
154
0- Saisir la demande DU 2- diter les fiches de demande
DS
3- Proposer les attributions de moyens
Utilisateur
6- Notifier les moyens arbitrs
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 attributions 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 automatiquement.
155
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 1- Grer les cadrages
156
<<systme>> : ALLOC
: DS_ demanderFiches(DS) liste units choisirUnits(listeUnits)
fiches de demande
Figure 5.6 DSE du cas dutilisation 2- diter les 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
Figure 5.7 DSE du cas dutilisation 3- Proposer les attributions de moyens
157
<<systme>>
: ALLOC
: CO
demanderChoisirTypemoyen( )
demandeConsoliderPropositions(typemoyen)
choix des rubriques du fichier consoliderPropRubriques(listeRubriques)
fichier de consolidation
Figure 5.8 DSE du cas dutilisation 4- Grer les moyens proposs
<<systme>> : ALLOC : CO
demanderChoisirTypemoyen( ) demanderSaisirArbitrage(DS, typemoyen)
cran arbitrage saisirArbitrage(dateArbitrage)
confirmer arbitrage saisi validerArbitrage(codeV)
Figure 5.9 DSE du cas dutilisation 5- Enregistrer larbitrage DG des propositions
158
<<systme>> : ALLOC
: DS demanderNotifierMoyens(DS)
fichier des lettres de notification
Figure 5.10 DSE du cas dutilisation 6- Notifier les moyens arbitrs
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.
2- diter les fiches de demande Directeur d'unit 3- Proposer les attributions de moyens <<include>> 6- Notifier les moyens arbitrs DS 5- Enregistrer l'arbitrage DG des attributions Utilisateur DG 8- Suivre lavancement des attributions <<extend>> CO 4- Grer les moyens proposs Point dextension si besoin tableau de suivi 7- Choisir type de moyens <<include>> <<include>>
1- Grer les cadrages
<<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
160
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. Scnarios alternatifs 2-a Modification des donnes de cadrage : Le systme affiche le formulaire de saisie des donnes de cadrage enregistres. Le coordonnateur modifie les donnes. Le cas dutilisation reprend laction 3 du scnario nominal. 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 dtectes. Le coordonnateur corrige les erreurs. Le cas dutilisation reprend au point 3 du scnario nominal.
161
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 llaboration 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
: CO
demanderChoisirTypemoyen( ) demanderSaisirCadrage(DS, typemoyen) demanderSaisirCadrage(DS, typemoyen) cran cadrage saisirCadrage (nombre)
cran cadrage saisirCadrage(nombre)
confirmerSaisie(accord)
validerSaisie(typemoyen, accord)
afficherCadrage(DS, typemoyen)
afficherCadrage(DS, typemoyen)
cadrage modifierCadrage(nombre)
cadrage modifierCadrage(DS, typemoyen, nombre) cadrage modifi
cadrage modifi
Figure 5.13 Diagramme de squence du cas dutilisation 1- Grer les cadrages
Tableau 5.1 Donnes de linterface utilisateur du cas dutilisation 1 Donnes affiches - Code et intitul DS - Code et intitul du type de moyen traiter - Nombre correspondant au cadrage du type de moyen slectionn Donnes saisies - DS et typemoyen - Nombre correspondant au cadrage du type de moyen slectionn - Validation
162
InterfaceUtilisateur -nom -prenom -id +saisirCadrage() +afficherCadrage() +modifierCadrage() +demanderChoisirTypemoyen() +confirmerSaisie() +demanderSaisirCadrage()
Cadrage-DS -DStypeMoyenC -cadrageA -date +afficherCadrage() +saisirCadrage() +validerSaisie() +modifierCadrage() +demanderSaisirCadrage()

fixer 1..* 1
DS -codeDS -intitulDS
cadrer 1..* 1 TypeMoyen

-typemoyen -intitulTypemoyen
Figure 5.14 Diagramme de classe du cas dutilisation 1
Cas dutilisation 2- diter les fiches de demande Description textuelle du cas dutilisation
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 slectionnes.
Description des diagrammes danalyse du cas dutilisation La suite de lanalyse du cas dutilisation se poursuit par llaboration du diagramme de squence (fig. 5.15), llaboration de linterface utilisateur (tab. 5.2) et llaboration du diagramme de classe (fig. 5.16). Cas dutilisation 3- Proposer les attributions de moyens Description textuelle du cas dutilisation
Objectif Permettre au DS de saisir ou de consulter des propositions dattributions. Acteur concern DS. Pr condition Aucune.
: InterfaceUtilisateur : Unit : Demande : Histo-Demande-RH : Histo-Attribution-RH
: DS
: Histo-Demande-RF
: Histo-Attribution-RF
: DS_
demanderFiches(DS)
llisterUnits(DS)
Pour toutes les units d'un DS loop llisterUnits()
lliste units Pour toutes les units de la liste
lliste units
choisirUnits(listeUnits)
loop extraireFiche(codeDS, listeUnits) extraireDemandeF() extraireHistoD-RH() extraireHistoA-RH() extraireHistoD-RF()
extraireUnit(codeUnit)
extraireHistoA-RF()
fiches
fiches de demande
Figure 5.15 Diagramme de squence du cas dutilisation 2
163
164
Tableau 5.2 Donnes de linterface utilisateur du cas dutilisation 2 Donnes affiches - Code et intitul DS - Liste des units du DS 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 - Codes units choisies Donnes saisies
DS -codeDS -intitulDS +listerUnits() +extraireFiche() rattacher 1 1..* Unit Histo-Attribution-RH allouer-histoRH -numAttribHA-RH -dateAttribHA-RH -gradeHA-RH 1..* -nombreHA-RH -extraireHistoA-RH() allouer-histoRF Histo-Demande-RH Histo-Demande-RF -numDemandeHD-RF -dateDemandeHD-RF -typemoyensHD-RF -montantHD-RF -justificationHD-RF +extraireHistoD-RF() 1..* demander-histoRF 1..* Histo-Attribution-RF -numAttribHA-RF -dateAttribHA-RF -typeMoyensHA-RF -montantHA-RF +extraireHistoA-RF()
-code unit 1 Demande mettre -intitul unit -nom directeur -numDemande 1 1..* 1 -adresse rue -dateDemande -adresse ville -adresse code postal +extraireDemandeF() +listerUnits() 1
InterfaceUtilisateur -nom -prenom -id +demanderFiches() +choisirUnits()
-numDemandeHD-RH 1..* -dateDemandeHD-RH 1 -gradeHD-RH demander-histoRH -nombreHD-RH -justificationHD-RH +extraireHistoD-RH()
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.
165
Scnarios alternatifs 4-a Saisie dune proposition dattribution sans demande pralable Le systme affiche le formulaire de saisie des propositions dattribution vierge. Le cas dutilisation reprend laction 5 du scnario nominal. 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. Le cas dutilisation reprend laction 5 du scnario nominal. 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 Le systme raffiche le formulaire de saisie en indiquant les erreurs dtectes. Linstructeur corrige les erreurs. Le cas dutilisation reprend au point 6 du scnario nominal.
: InterfaceUtilisateur : DS_ demanderChoisirTypemoyen()
: DS
: Unit
: Demande
: Attributions
loop Toutes les units du DS demanderProposerAttribution(DS, typemoyen) listerUnits(DS) extraireUnits() unit extraite liste units choisirUneunit(codeUnit) cran de saisie d'une attribution saisirAttribution(typemoyen, codeUnit, nombre) contrlerAttribution(typemoyen, codeUnit, nombre) rsultat contrle validerAttribution(codevalid) attribution enregistre attribution enregistre liste units afficherSaisieAttribution(codeUnit, typemoyen) extraireDemandeP(codeUnit, typemoyen)
rsultat du contrle des donnes saisies validerAttribution(codevalid)
Dans le DSE, seul le scnario nominal est reprsent pour le traitement dune unit. La recherche de lintitul DS et type de moyen na pas t traite.
166
Tableau 5.3 Donnes de linterface utilisateur du cas dutilisation 3 Donnes affiches - Code et intitul DS - Code et intitul du type de moyen traiter - Demande RH - Demande RF - Attribution propose RH - Attribution propose RF Donnes saisies - DS et typemoyen - Code de lunit traiter - Nombre propos pour le type de moyens trait - Validation de la saisie
Attributions correspondre InterfaceUtilisateur -nom -prenom -id +saisirAttribution() +validerAttribution() +demanderChoisirTypemoyen() +demandeProposerAttribution() +choisirUneunit() -numAttrib -dateAttrib 0..* +contrlerAttribution() +validerAttribution() DS 1..* 0..1 Demande -numDemande -dateDemande +extraireDemandeP() allouer 1 Unit -code unit -intitul -nom directeur i -adresse rue -adresse ville -adresse code postal +afficherSaisieAttribution() +listerUnits() 1..* rattacher 1 -codeDS -intitulDS +listerUnits()
TypeMoyen -typemoyen -intitulTypemoyen
mettre
Cas dutilisation 4- Grer les moyens proposs Description textuelle du cas dutilisation
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. Acteur concern Coordonnateur. Pr condition Aucune. Scnario nominal 1 Le coordonnateur choisit le type de moyen traiter. 2 Le coordonnateur demande extraire le fichier pour la consolidation des propositions dattribution.
167
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 : CO : DS : Unit : Demande : Attributions
demanderChoisirTypemoyen() demanderListeRubriques(typemoyen) liste rubriques choisir

L'obtention de la liste des rubriques disponibles pour unit et attributions n'est pas reprsente
demanderConsoliderPropositions(typemoyen)
choix des rubriques du fichier
loop consoliderPropRubriques(listeRubriques)
Pour tous les DS
Pour toutes les units d'un DS loo 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
Tableau 5.4 Donnes de linterface utilisateur du cas dutilisation 4 Donnes affiches - Code et intitul type moyen - Liste des rubriques du fichier - Nombre correspondant aux demandes et aux moyens proposs - Type moyen - Liste des rubriques choisies Donnes saisies
168
Attributions
InterfaceUtilisateur -nom -prenom -id +consoliderPropRubriques() +demanderConsoliderProposition() +demanderChoisirTypemoyen()
correspondre 0..*
-numAttrib -dateAttrib +extraireAttributionG() allouer 0..*
0..1 Demande -numDemande -dateDemande 0..* emettre 1
1 Unit -code unit -intitul unit -nom directeur -adresse rue -adresse ville 1..* -adresse code postal +extraireDemandeG() +demanderListeRubriques() +exraireAttributionG()
+extraireDemandeG()
DS -codeDS -intitulDS +extraireMoyensP() 1
rattacher
Cas dutilisation 5- Enregistrer larbitrage DG des propositions Description textuelle du cas dutilisation
Objectif Permettre au coordonnateur de saisir larbitrage de la direction. Acteur concern Coordonnateur. 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.
Scnarios alternatifs 5-a Erreurs dtectes dans la saisie : Le systme raffiche le formulaire de saisie en indiquant les erreurs dtectes. Le coordonnateur corrige les erreurs. Le cas dutilisation reprend au point 4 du scnario nominal.
169
: Cadrage-DS
: CO
demanderChoisirTypemoyen() demanderSaisirArbitrage(DS, typemoyen) cran arbitrage saisirArbitrage(dateArbitrage) afficherArbitrage(DS, typemoyen) cran arbitrage modifierArbitrage(dateArbitrage) arbitrage modifi validerArbitrage(codeV)
confirmer arbitrage saisi validerArbitrage(codeV)
Seul le scnario nominal est reprsent dans le DSE. La recherche de lintitul type moyen nest pas aussi reprsente.
Tableau 5.5 Donnes de linterface utilisateur du cas dutilisation 5 Donnes affiches - Code et intitul du type de moyen traiter - Date de larbitrage Donnes saisies - DS et type de moyen traiter - Date darbitrage - Code validation
InterfaceUtilisateur -nom -prenom -id +saisirArbitrage() +demanderChoisirTypemoyen() +demanderSaisirArbitrage() +validerArbitrage() Cadrage-DS -typeMoyenC -cadrageA -date arbitrage +afficherArbitrage() +validerArbitrage() +modifierArbitrage() cadrer 1..* 1
170
Cas dutilisation 6- Notifier les moyens arbitrs Description textuelle du cas dutilisation
Objectif Permettre au DS de produire les lettres informant les directeurs dunit des moyens qui leur sont allous. Acteur concern DS. Pr condition Aucune. Scnario nominal 1 Le DS demande lextraction du fichier pour ldition des lettres type dattribution de moyens. 2 Le systme gnre le fichier des lettres de notification.
: InterfaceUtilisateur : DS : Unit : Attributions
: DS_
demanderNotifierMoyens(DS)
loop notifierMoyens(DS)
toutes les units du DS notifierMoyens() extraireAttributionN(typemoyen)
attributions d'une unit attributions d'une unit fichier des lettres de notification attribution de toutes les units
Figure 5.23 Diagramme de squence du cas dutilisation 6 Tableau 5.6 Donnes de linterface utilisateur du cas dutilisation 6 Donnes affiches - Code et intitul du DS Pour chaque unit concerne : - Code - Intitul - Adresse - Nom du directeur - Type moyen et nombre correspondant au moyen attribu (pour toutes les attributions). - Code du DS Donnes saisies
171
Attributions-RH Attributions InterfaceUtilisateur -nom -prenom -id +demanderNotifierMoyens() Unit 0..* -code unit -intitul unit -nom directeur -adresse rue -adresse ville -adresse code postal +notifierMoyens() DS 1..* 1 +codeDS +intitulDS +notifierMoyens() -numAttrib -dateAttrib +extraireAttributionN() -gradeA -nombreA Attribution-RF -typeMoyensA -montantA
1 allouer
rattacher
Cas dutilisation 7- Choisir un type de moyen Description textuelle du cas dutilisation

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.
: InterfaceUtilisateur : Cadrage-DS
: Utilisateur
demanderChoisirTypemoyen() liste des types de moyen
listerTypemoyens()
choisirUntypemoyen(typemoyen)
172
Tableau 5.7 Donnes de linterface utilisateur du cas dutilisation 7 Donnes affiches - Liste des types de moyen proposs Donnes saisies - Code du type de moyen choisi
InterfaceUtilisateur -nom -prenom -id +demanderChoisirTypemoyen() +choisirUntypemoyen()
Cadrage-DS -DStypeMoyenC -cadrageA -date cadrage TypeMoyen cadrer 1 -typemoyen -intitulTypemoyen
+listerTypemoyens() 1..*
Cas dutilisation 8 Suivre lavancement des attributions Description textuelle du cas dutilisation
Objectif Mettre la disposition des dpartements scientifiques un ensemble de tableaux de suivi des attributions des moyens aux units. Acteur concern Coordonnateur. 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
: DS
: Cadrage-DS
: Unit
: Attributions
: DS_ demanderTableauxdesuivi(typemoyen, DS) afficher le choix des tableaux de suivi construireTableaudesuivi(DS, typemoyen) extraireCadrage() choisirUntableaudesuivi() loop Toutes les units du DS construireTableaudesuivi(typemoyen) donnerAttribution() attributions dune unit
afficher le tableau de suivi
attributions de toutes les units
Tableau 5.8 Donnes de linterface utilisateur du cas dutilisation 8 Donnes affiches - Liste des tableaux de suivi Donnes saisies - Choix du tableau de suivi
Attributions -numAttrib -dateAttrib +donnerAttribution() 0..* allouer 1 Unit InterfaceUtilisateur -nom -prenom -id +demanderTableauxdesuivi() +choisirUntableaudesuivi() -code unit -intitul unit -nom directeur -adresse rue -adresse ville -adresse code postal +construireTableaudesuivi()
Cadrage-DS -DStypeMoyenC -cadrageA -date arbitrage +extraireCadrage()
1..* fixer rattacher 1..* 1 -codeDS -intitulDS +construireTableaudesuivi() 1 DS
174
Attributions-RH 1..* cadrer -nom -prenom -id 1 InterfaceUtilisateur -DStypeMoyenC -cadrageA -date arbitrage 1..* er 1 DS -codeDS -intitulDS +extraireFiche() +extraireMoyenP() +listerUnits() ens() rattacher 1 1..* Histo-Attribution-RH 1 allouer-histoARH -numAttribHA-RH 1..* -dateAttribHA-RH -gradeHA-RH -nombreHA-RH +extraireHistoA-RH() Histo-Attribution-RF -numAttribHA-RF -dateAttribHA-RF -typeMoyensHA-RF -montantHA-RF +extraireHistoA-RF() +extraireHistoD-RH() +choisirUneunit() +choisirUnits() +choisirUntableaudesuivi() +choisirUntypemoyen()
Attributions
Cadrage-DS
-gradeA -nombreA
-numAttrib -dateAttrib
Attribution-RF +demanderSaisirCadrage() +extraireCadrage() +listerTypemoyens() +saisirCadrage() +validerArbitrage() +validerSaisie()
+contrlerAttribution() +donnerAttribution() +extraireAttributionG() -typeMoyensA correspondre +extraiteAttributionN() -montantA +validerAttribution() 0..* 1..* allouer Demande 0..1 1 -numDemande mettre Unit -dateDemande 0..* 1 -code unit +extraireDemandeF() -intitul unit +extraireDemandeG() -nom directeur +extraireDemandeP() -adresse rue -adresse ville -adresse code postal Demande-RH Demande-RF +saisirArbitrage() +saisirAttribution() +saisirCadrage() +validerArbitrage() +validerAttribution()
+consoliderPropRubriques() +demanderChoisirTypemoyen() +demanderConsoliderProposition() +demanderFiches() ens() +demanderProposerAttribution() +demanderSaisirCadrage() +demanderTableauSuivi()
-gradeD -nombreD
+construireTableaudesuivi() +demanderListeRubriques() 1 allouer-histoARF +extraireAttributionsG() 1..* +extraireDemandeG() Histo-Demande-RF +listerUnits() Histo-Demande-RH ens() -numDemandeHD-RF -numDemandeHD-RH -dateDemandeHD-RF 1..* 1..* -dateDemandeHD-RH -typemoyensHD-RF 1 -gradeHD-RH 1 -montantHD-RF demander-histoDRH -nombreHD-RH demander-histoDRF
-typeMoyensD -montantD
+extraireHistoD-RF()
Figure 5.29 Diagramme de classe de synthse
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 simultanes 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 contiennent 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 rapports 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 et des activits
Facturation
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 transmises 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.
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 communique]
[Frais 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 lentreprise 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.
178
Profil +libell possde Utilisateur 1 1..* +nom +prnom +identifiant ralise 1 1..* Activit +charge correspond 1..* 1 Date +jour +mois +anne
appartient 1..* 1 Division +libell
1..*
engage
se rapporte
0..* Frais +montant se rapporte 0..* 1
1 Projet +code projet +libell
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 formulaires utiliss avant informatisation : le relev mensuel dactivit et le relev mensuel de frais.
Figure 6.4 Relev mensuel dactivit
179
180
Figure 6.5 Relev mensuel de frai
Figure 6.5 Relev mensuel de frais
181
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 prvisionnels (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 retrouver pour une journe donne, les frais prvisionnels dun employ.
182
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 messagerie, 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 manager 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
183
<<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>> Gestion des frais et activits : Manager consulterTableaux(projet,mdebutPriode,adebutPeriode,mfinPriode, afinPriode )
alt [debutPeriode = finPeriode || debutPeriode > finPeriode] [dbutPriode finPriode dbutPriode finPriode] priode mal renseigne [priode [periode OK] 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
184
<<system>> Gestion des frais et activits : Secrtaire <<Systme externe>> : Service facturation
exporterActivitFrais() importerActivitFrais() la fin de chaque mois
Figure 6.10 DSE du CU Exporter activits et frais
<<system>> Gestion des frais et activits : 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.
185
[ secrtaire ou manager ]
Tableaux de bord
[ manager ] Exportation activit et frais
Accueil
[ secrtaire ou manager ] Relance activit
[ 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 paragraphe prcdent. En effet, nous sommes passs dans une phase danalyse qui correspond une vue informatique du systme et nous avons identifi 13 cas dutilisation.
186
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
Consulter tableaux de bord
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
187
Consulter tableaux de bord 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 Description textuelle du cas dutilisation

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 donne. 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.
Description des diagrammes danalyse du cas dutilisation La suite de lanalyse du cas dutilisation se poursuit par llaboration du diagramme de squence (fig. 6.14), llaboration de linterface utilisateur (fig. 6.15) et llaboration du diagramme de classe (fig. 6.16).
188
: 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 Code projet 2
0.5 0.5
0.5 0.5
4j 1j Total : 5 j
Ajouter un code Valider
Figure 6.15 cran Saisir Activit
189
Date -jour -mois -anne +getDate(jour, mois, anne) 1 correspond Utilisateur -nom -prnom -identifiant -mot de passe +saisirActivit(charge, code projet, jour, mois, anne) ralise 1 -charge 1..* Activit 1..* +Activit(charge, code projet, jour, mois, anne) +checkActivitePositive(charge) 1..* se rapporte 1 Projet -code projet -libell
Figure 6.16 Diagramme de classe du CU Saisir activit
Cas dutilisation Consulter activit Description textuelle du cas dutilisation

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.
190
Description des diagrammes danalyse du cas dutilisation La suite de lanalyse du cas dutilisation se poursuit par llaboration du diagramme de squence (fig. 6.17), llaboration de linterface utilisateur (fig. 6.18), et llaboration du diagramme de classe (fig. 6.19).
: Utilisateur
: Activit
: Date
: Employ getActivits(mois) checkActivitMois(mois)
loop
getDate()
comparerMois(mois)
activits
calculTotalMoisActivit(mois)
Pour toutes les activits enregistres, 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
191
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 CP2 1 1 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 +getDate(jour, mois, anne) +comparerMois(mois) 1
correspond
1..* Utilisateur -nom -prnom -identifiant -mot de passe +saisirActivit(charge, code projet, jour, mois, anne) +getActivits(mois) +calculTotalMoisActivit(mois) +checkActivitMois(mois) 1 Activit -charge ralise 1..* +Activit(charge, code projet, jour, mois, anne) +getDate() +checkActivitPositive(charge)
Figure 6.19 Diagramme de classe du CU Consulter activit
192
Cas dutilisation Relancer activit Description textuelle du cas dutilisation

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 partiellement) leur activit mensuelle. 2 La secrtaire valide cette liste. 3 Lapplication envoie un courriel de relance aux employs concerns. Scnarios alternatifs 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.
Description des diagrammes danalyse du cas dutilisation 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).
193
: 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 cette mthode est faux, il est ajout dans les utilisateurs relancer. getMail()
utilisateursARelancer envoiMailUtilisateurs(listUtilisateurs) loop
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 employs ont rempli leur activit .
194
: Utilisateur
: Secrtaire getUtilisateursRelance() checkDateMois()
erreur jour du mois courant < 10
Jour du mois courant > 10
getUtilisateursRelance() checkDateMois()
erreur
Vrification que tous les utilisateurs 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)
195
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 +saisirActivit(charge, code projet, jour, mois, anne) +getActivits(mois) +checkActivitMois(mois) +calculTotalMoisActivit(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 Description textuelle du cas dutilisation

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.
196
Scnario nominal 1 Le manager slectionne une priode (mois, anne). 2 Lapplication propose des tableaux de bord sur la priode et la division du manager concernant lactivit par projet (nombre de jours/h par projet), le taux dactivit (nombre de jour/h sur un projet / nombre de jour/h total de la priode). 3 Lapplication propose aussi un affichage de graphiques. Scnarios alternatifs 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 identique 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 slectionne. Lapplication affiche un message indiquant quaucun employ na saisi son activit ou ses frais. Le cas dutilisation se termine en chec.
Description des diagrammes danalyse du cas dutilisation 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.
197
: Projet
: Utilisateur
: Activit
: Division
: Date
: Manager
calculNbJoursProjet(moisDebut, anneeDebut, moisFin, anneeFin, identifiant) getUtilisateur(identifiant) Pour tous les projets getDivision() getCodeDivision() Une somme de toutes les charges par projet est ralise si le projet appartient la priode slectionne
Si le projet appartient la mme division que le manager
loop
isProjetMemeDivision(code division)
opt Pour toutes les activits du projet loop getDate()
isDansPeriode(moisDebut, anneeDebut, moisFin, anneeFin)
opt Un cumul des charges par projet est retourn
getCharge()
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
198
Slection tableaux de bord Slectionner une priode pour afficher les tableaux de bord pour la division Industrie : Dbut priode : Fin priode : Mois Anne
Mois
Anne
Valider
Figure 6.25 cran Slection tableaux de bord
Consulter 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 Code projet 1 Code projet 2 Code projet 3 Code projet 4 Code projet 5 Activit (j/h) 100 80 80 30 70
Taux dactivit de la division Industrie pour la priode novembre/dcembre : Priode Novembre/dcembre Taux dactivit de la division (%) 90 graphiques
Figure 6.26 cran Consulter tableaux de bord
199
Date -jour -mois -anne +getDate(jour, mois, anne) +comparerMois(mois) +isDansPeriode(moisDebut, anneeDebut, moisFin, anneeFin) +nbJoursDansPeriode(moisDebut, anneeDebut, moisFin, anneeFin) 1
Utilisateur -nom -prnom -identifiant -mot de passe -mail +saisirActivit(charge, code projet, jour, mois, anne) +getActivites(mois) +calculTotalMoisActivit(mois) +getUtilisateursRelance() +isActiviteComplete(mois) +checkDateMois() +checkAllActiviteComplete() +envoiMailUtilisateurs(listUtilisateurs) +getMail() +envoiMail(mail) +getUtilisateur(identifiant) +getDivision() ralise 1 1..*
correspond 1..* Activit -charge +Activit(charge, code projet, jour, mois, anne) +modifier(charge) +getDate() +getCharge() +checkActivitePositive(charge) 1..*
se rapporte 1..*
appartient 1 Projet 1 Division -code division -libell +getCodeDivision() est rattach 1 1..* -code projet -libell +getProjet(code projet) +isProjetMemeDivision(code division) +calculTauxActivite(moisDebut, anneeDebut, moisFin, anneeFin, identifiant) +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
200
Cas dutilisation Crer utilisateur Description textuelle du cas dutilisation

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.
Scnarios alternatifs 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.
Description des diagrammes danalyse du cas dutilisation La suite de lanalyse du cas dutilisation se poursuit par llaboration du diagramme de squence (fig. 6.28), llaboration de linterface utilisateur (fig. 6.29) et llaboration du diagramme de classe (fig. 6.30).
201
: 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
202
Utilisateur -nom -prnom -identifiant -mot de passe -mail +Utilisateur(nom, prnom, profil, mail) +saisirActivit(charge, code projet, jour, mois, anne) +rechercheActivit(code projet, jour, mois, anne) +supprimerActivit(code projet, jour, mois, anne) +getActivits(mois) +calculTotalMoisActivit(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 +Profil(libell) +modifier(libell) +getCodeProfil() +getLibell()
possde
6.5 Synthse de lanalyse
Date -jour -mois -anne 1
0..*
correspond
Utilisateur
-nom -prnom -identifiant -mot de passe -mail 1..* Activit -charge ralise 1 1..* 1..* se rapporte
+Date(jour, mois, anne) +getDate(jour, mois, anne) +setDate(jour, mois, anne) +comparerMois(mois) +isDansPeriode(moisDebut, anneeDebut, moisFin, anneeFin) +nbJoursDansPeriode(moisDebut, anneeDebut, moisFin, anneeFin)
+Activit(charge, code projet, jour, mois, anne) +modifier(charge) +getDate() +checkActivitePositive(charge) +getCharge() correspond
1 0..* Frais -montant -trajet engage 0..* +Frais(montant, trajet, jour, mois, anne) +modifier(montant, trajet) +getDate() 0..* -code projet -libell Projet
+Utilisateur(nom, prnom, profil, mail) +modifier(nom, prnom, profil, mail) +saisirActivit(charge, code projet, jour, mois, anne) +saisirFrais(montant, trajet, jour, mois, anne) +modifierActivit(charge, code projet, jour, mois, anne) +modifierFrais(montant, code projet, jour, mois, anne) +rechercheActivit(code projet, jour, mois, anne) +supprimerActivit(code projet, jour, mois, anne) +rechercheFrais(code projet, jour, mois, anne) +supprimerFrais(code projet, jour, mois, anne) +getActivites(mois) +calculTotalMoisActivit(mois) +calculTotalMoisFrais(mois) +getFrais(mois) +checkDateMois() +checkAllActiviteComplete() +getUtilisateursRelance() +isActiviteComplete(mois) +envoiMailUtilisateurs(listUtilisateurs) +getMail() +envoiMail(mail) +getUtilisateur(identifiant) +getDivision() +checkNomPrenom() +checkMail() +generateIdentifiantPassword() 1
+Projet(code projet, libell) +modifier(libell) +getProjet(code projet) +getProjetsActivite(moisDebut, anneeDebut, moisFin, anneeFin, identifiant) +isProjetMemeDivision(code division) +calculTauxActivite(moisDebut, anneeDebut, moisFin, anneeFin, identifiant) +calculNbJoursProjet(moisDebut, anneeDebut, moisFin, anneeFin, identifiant) +calculNbjoursTotalPeriode(moisDebut, anneeDebut, moisFin, anneeFin)
1..* 1..*
Division -code division -libell
appartient 1
1 +creer(libell) +modifier(libell) +getCodeDivision() +getLibell() est rattach
203
Figure 6.31 Diagramme de classe rcapitulatif
204
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 Grer activits Grer activits Grer activits Grer frais Grer frais Grer frais Relancer activit Consulter tableaux de bord Exporter activits et frais Consulter frais Relancer activit Consulter tableaux de bord Exporter activits et frais Crer utilisateur Consulter activit Saisir frais Cas dutilisation analyse Saisir activit
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 la saisie de l'employ: - une liste de charges - une liste de dates (format date : jj/mm/aaaa) - une liste de code projet
getIdentifiant()
loop
<<create>> Activit(charge, code projet, date, id utilisateur) getProjet(code projet)
save()
Cette mthode fait appel au contexte de l'application pour rcuprer l'utilisateur actif (Session pour les applications Web). Le contexte n'a pas t modlis ici.
Pour toutes les activits de la semaine
Figure 6.33 Diagramme de squence technique du CU Saisir activit
La navigabilit des associations est donne par le sens de circulation des oprations du diagramme de squence (fig. 6.33). Ainsi, la classe Dialogue Saisir Activit accde la classe CTRL Saisir Activit par le biais du message saisirActivit. 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.
206
La contrainte ordered entre Utilisateur et Activit exprime la relation de tri par date croissante des Activit dans la collection Utilisateur .
CollectionProjet contient +getProjet(code projet: String): String 0..* {ordered} 1..* Projet -code projet: String -libell: String
1 se rapporte 1..* Utilisateur -nom: String -prnom: String -identifiant: String -mot de passe: String +getIdentifiant(): String 1 ralise 1 Activit {ordered} -charge: Float -date: Date 1..* +Activit(charge: Float, code projet: String, date: Date, id utilisateur: +save(): void 1
1 <<Contrleur>> CTRL Saisir Activit
+saisirActivit(charges: List, dates: List, codes projet: List): +checkActivitePositive(charges: List): +getUtilisateurActif():
Type Standard Date indpendant du langage de programmation
<<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 diagramme de classe technique (fig. 6.36) sont ralises. La navigabilit des associations est donne par le sens de circulation des oprations 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
consulterActivit(mois) consulterActivit(mois)
getUtilisateurActif()
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
List List
Traitement identique celui de getActivit(mois), avec 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.
208
DateUtils +comparerMois(date: Date, mois): Boolean
Utilisateur -nom: String -prnom: String -identifiant: String -mot de passe: String +getActivites(mois: String): List +getIdentifiant(): String +calculTotalMoisActivit(mois: String): Float +checkActiviteMois(mois: String): Boolean 1 1 Activit {ordered} 1..* -charge: Float -date: Date +Activit(charge: Float, code projet: String, date: DateUtils, id utilisateur: String ) +save(): void +getDate(): Date
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 llaboration 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 .
6.6 Conception
: Dialogue Relancer Activit
: CTRL Relancer Activit
: DateUtils
: CollectionUtilisateur
: Utilisateur
: Mail
: Secrtaire
FindUtilisateursRelance() FindUtilisateursRelance() checkDateMois()
getMoisCourant()
getUtilisateursRelance(mois) checkAllActiviteComplete()
loop isActiviteComplete(mois)
RelancerActivit(listUtilisateurs) RelancerActivit(listUtilisateurs) envoiMailUtilisateurs(listUtilisateurs) loop
Pour chaque utilisateur, on vrifie si l'activit est complte pour le mois slectionn, si c'est le cas l'utilisateur est ajout la liste retourne.
Figure 6.37 Diagramme de squence technique du CU Relancer activit (scnario nominal)
getMail()
<<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
210
: Dialogue Erreur Relancer Activit
: Dialogue Relancer Activit
: CTRL Relancer Activit
: DateUtils
: CollectionUtilisateur
: Secrtaire FindUtilisateursRelance() FindUtilisateursRelance() checkDateMois()
messageErreur creer(messageErreur) <<create>>
Le jour du mois courant est < 10 FindUtilisateursRelance() FindUtilisateursRelance() 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)
La navigabilit des associations est donne par le sens de circulation des oprations 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 -identifiant: String -mot de passe: String -mail: String +getActivites(mois: String): List +getIdentifiant(): String +calculTotalMoisActivit(mois: String): Float +checkActiviteMois(mois: String): Boolean 0..* +isActiviteComplete(mois: String): Boolean +envoiMailUtilisateurs(listUtilisateurs: List): void contient +getMail(): String 1 CollectionUtilisateur +checkAllActiviteComplete(): Boolean +getUtilisateursRelance(mois: String): List 1 1 1 <<Contrleur>> CTRL Relancer Activit +FindUtilisateursRelance(): List +RelancerActivit(listUtilisateurs: List): void DateUtils +comparerMois(date: Date, mois): Boolean +checkDateMois(): Boolean +getMoisCourant(): String 1 -dest: String -from: String -body: String +Mail(dest: String, from: String, body: String) +send(): void
Mail
<<Dialogue>> Dialogue Erreur Relancer Activit <<Dialogue>> Dialogue Relancer Activit +mois: String +FindUtilisateursRelance(): List +RelancerActivit(listUtilisateurs: List): void +messageErreur: String +creer(messageErreur)
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 diagramme de classe technique (fig. 6.41) sont ralises.
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)
getUtilisateurActif()
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 manager opt getCharge()
isDansPeriode(date, moisDebut, anneeDebut, moisFin, anneeFin)
Un cumul des charges par projet est retourn sous forme de liste
List calculTauxActivite(moisDebut, anneeDebut, moisFin, anneeFin)
Une somme de toutes les charges par projet est ralise si le projet appartient la priode slectionne
calculNbJoursTotalProjet(moisDebut, anneeDebut, moisFin, anneeFin, code division)
La liste retourne contient le cumul des charges par projet + taux activit Mme traitement que CalculNbJousProjet mais un cumul total des charges des projets est retourn
nbJoursDansPeriode(moisDebut, anneeDebut, moisFin, anneeFin)
Float List
Figure 6.40 Diagramme de squence technique du CU Consulter tableaux de bord
Utilisateur Activit ralise {ordered} 1..* +Activit(charge: Float, code projet: String, date: Date, id utilisateur: String) +save(): void +getDate(): Date +getCharge(): Float 1..* 1 -charge: Float -date: Date
6.6 Conception
-nom: String -prnom: String -identifiant: String -mot de passe: String -mail: String
+getActivites(mois: String): List +getIdentifiant(): String +calculTotalMoisActivit(mois: String): Float +checkActiviteMois(mois: String): Boolean +getUtilisateursRelance(mois: String): List +isActiviteComplete(mois: String): Boolean +envoiMailUtilisateurs(listUtilisateurs: List): void +getMail(): String +getDivision(): Division DateUtils se rapporte +comparerMois(date: Date, mois: String): +checkDateMois(): +isDansPeriode(date: Date, moisDebut, anneeDebut, moisFin, anneeFin): Boolean +nbJoursDansPeriode(moisDebut, anneeDebut, moisFin, anneeFin): Integer 1 Projet 1 est rattach +isProjetMemeDivision(code division: String): Boolean 1..* -code projet: String -libell: String
1..*
appartient
Division
-code division: String -libell: String
+getCodeDivision(): String 1
{ordered}
1..*
contient
Consulter tableaux de bord
Figure 6.40 Diagramme de squence technique du CU
1 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
213
Figure 6.41 Diagramme de classe technique du CU Consulter tableaux de bord
214
La navigabilit des associations est donne par le sens de circulation des oprations du diagramme de squence prcdent. Ainsi, la classe Dialogue Consulter TDB accde la classe CTRL Consulter TDB par le biais du message consulterTDB. 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 diagramme de classe technique (fig. 6.43) sont ralises.
: 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
La navigabilit des associations est donne par le sens de circulation des oprations 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 -identifiant: String -mot de passe: String -mail: String Mail -dest: String -from: String -body: String +Mail(dest: String, from: String, body: String) +send(): void +Utilisateur(nom: String, prnom: String, mail: String) +getActivites(mois: String): List +getIdentifiant(): String +calculTotalMoisActivit(mois: String): Float +checkActiviteMois(mois: String): Boolean +isActiviteComplete(mois: String): Boolean +envoiMailUtilisateurs(listUtilisateurs: List): void +getMail(): String +getDivision(): Division +generateIdentifiantPassword(): Boolean contient 0..*
6.6 Conception
1 1
CollectionUtilisateur
+checkAllActiviteComplete(listUtilisateurs: List): Boolean +getUtilisateursRelance(mois: String): List +add(utilisateur: Utilisateur): void 1 1 <<Contrleur>> CTRL Crer Utilisateur +CreerUtilisateur(nom: String, prnom: String, mail: String, profil: String): void +checkNomPrenom(): Boolean +checkMail(): Boolean 1
Figure 6.43 Diagramme de classe technique du CU Crer utilisateur
<<Dialogue>> Dialogue Crer Utilisateur -nom: String -prnom: String -mail: String -profil: String +CreerUtilisateur(nom: String, prnom: String, mail: String, profil: String): void
215
Figure 6.43 Diagramme de classe technique du CU Crer utilisateur
216
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 Contrleur et entre le paquetage Contrleur et Entit illustrent lindpendance des couches 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 transitivit. 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 utilitaire.
Gestion utilitaire
Gestion mail
<<import>>
<<import>>
Dialogue
<<access>>
Contrleur
<<access>>
Entit 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
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).
222
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 orientes 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 Processus 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.
224
[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, Prentice 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
acteur 62 action 73, 81 activit 73, 82, 113, 128 agrgation 3, 27, 28 analyse 116 des cas d'utilisation 125, 134 artefact 51, 53, 114 association 3, 23 attribut 19, 22
de structure composite 11, 58 de temps 12, 109 des cas dutilisation 11, 61 global dinteraction 12, 106 structurel 11
E
laboration 115 encapsulation 3 environnement 122 tat 2, 72 composite 75 historique 77 exigences fonctionnelles 125, 131 expression des besoins 116
B-C
bote blanche 48 noire 47 cas dutilisation 62 classe 2, 18 abstraite 33 classe-association 27 collaboration 58 compartiment 48 composant 46 composition 28 conception 117, 126, 142, 146 connecteur dassemblage 47 dinterfaces 47 construction 116 contrainte 10, 26 temporelle 92
F
fiche guide 128 flot de contrle 81 de donnes 86 fragment dinteraction 93
G
gnralisation 4, 32 gestion dun projet 122 de l'environnement 122 de la configuration et des changements 122 des exigences 121
D
dpendance 30 dinterfaces 47 entre paquetages 56 dploiement 121 diagramme dactivit 11, 80 dtat-transition 11, 72, 73 dobjet 11 de classe 11, 17 de communication 12, 104 de comportement 11 de composant 11, 46 de dploiement 11, 50 de paquetage 11, 54 de squence 11, 90
H-I
hritage 32 implmentation 117 inception 115 incrmental 112 instance 18 interaction 63 interface 31, 47 itratif 112 itration 116
J-L
jalon 119 ligne de vie 91
226
M
message 91, 104 mta-modle 8 modlisation mtier 121, 124, 128 modularit 6 multiplicit 24
N
navigabilit 25 nud 50, 53 de bifurcation 82 de fusion-test 85 de jonction 83 de test-dcision 84 note 10
de jonction 76 polymorphisme 4 port 49 post condition 67 pr condition 67 priv 22 processus 112, 119 profil 9 protg 22 public 22
Q-R
qualification 30 qualit 118 relation dextension 65 dinclusion 64 de gnralisation 65 rutilisabilit 6 risques 113 rle 24, 58, 104, 113 RUP 117
O
objet 2, 17, 21, 72, 105 OCL 10 oprateur alt 94 assertion 100 break 97 consider 98 critical 98 ignore 98 loop 94 negative 100 opt 94 par 96 ref 100 srict 97 weak 97 opration 20, 22
S
scnario alternatif 67 nominal 67 spcialisation 4 spcification de dploiement 51 strotype 9, 36 synthse de l'analyse 125, 140
T-U
tests 117 transistion 116 transition 72, 80, 81 UML 7 UP 8, 111 UP7 123
P
paquetage 22, 54 partition 87 persistance 5 phase 114 pin 86 point de choix 76
V-W
valeur marque 9 visibilit 22 workflow 114, 119
INFOPRO
TYPE DOUVRAGE L'ESSENTIEL SE FORMER RETOURS D'EXPRIENCE
MANAGEMENT DES SYSTMES D'INFORMATION APPLICATIONS MTIERS TUDES, DVELOPPEMENT, INTGRATION EXPLOITATION ET ADMINISTRATION
Joseph Gabay David Gabay
UML 2 ANALYSE ET CONCEPTION

Mise en uvre guide avec tudes de cas
Cet ouvrage sadresse tous les professionnels, concepteurs et dveloppeurs, qui souhaitent mieux matriser UML 2 et acqurir une dmarche pratique de mise en uvre ainsi quaux tudiants en informatique. Il propose une approche pdagogique de laspect normatif dUML 2 et une dmarche dlaboration des diagrammes couvrant lanalyse et la conception des systmes dinformation. Le lecteur suit un apprentissage progressif fond sur de nombreux exemples, exercices corrigs et de vritables tudes de cas se rapprochant de projets rels dentreprise. Cette dition sert trois objectifs : 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.
RSEAUX & TLCOMS
JOSEPH GABAY est directeur de projet informatique au CNRS. Il assure galement des enseignements dUML luniversit de ParisDauphine ainsi quen IUT en en cycle BTS. Il est lauteur de plusieurs ouvrages sur UML.
DAVID GABAY est ingnieur et chef de projet chez CapGemini.
ISBN 978-2-10-053567-5
www.dunod.com

Uml 2 Analyse Et Conception (Dunod)

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Uml 2 Analyse Et Conception (Dunod)

Enviado por

Direitos autorais:

Formatos disponíveis

UML 2

Joseph Gabay David Gabay

Illustration de couverture : Mountain, DAJ, Hokkaido Source : gettyimages

Dunod, Paris, 2008

Tables des matires

1.2 Prsentation gnrale dUML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

UML2 analyse et conception

2.1.3 2.1.4 2.1.5 2.1.6 2.1.7 2.1.8

3.2 Diagramme dtat-transition (DET) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Tables des matires

UML2 analyse et conception

Tables des matires

UML, une volution majeure dans le domaine des mthodes

UML2 analyse et conception

UML2 analyse et conception

qui sadresse ce livre ?

1.1 CONCEPTS DE LAPPROCHE OBJET

Chapitre 1. Concepts de lapproche objet et prsentation dUML 2

1.1.1 Objet et classe

1.1 Concepts de lapproche objet

1.1.2 Encapsulation et interface

1.1.3 Association et agrgation entre les classes

Chapitre 1. Concepts de lapproche objet et prsentation dUML 2

1- Oprations accessibles - opration 1 - opration 2 - opration 3

Donnes : liste des attributs

2- Oprations non accessibles - opration A - opration B

Figure 1.1 Schma de principe de lencapsulation

1.1.4 Gnralisation et spcialisation de classe

1.1 Concepts de lapproche objet

Exemple Soit la classe Employ et ses deux sous-classes Cadre et NonCadre.

Chapitre 1. Concepts de lapproche objet et prsentation dUML 2

1.1.7 Avantages du dveloppement laide des langages objet

1.2 PRSENTATION GNRALE DUML

1.2 Prsentation gnrale dUML

1.2.2 Structuration de la prsentation

Chapitre 1. Concepts de lapproche objet et prsentation dUML 2

1.2.3 Rgles gnrales

1.2 Prsentation gnrale dUML

Figure 1.2 Exemple dune classe strotype

Chapitre 1. Concepts de lapproche objet et prsentation dUML 2

Ce modle reprsente la vue des gestionnaires

Figure 1.3 Formalisme et exemple dutilisation dune note

{le parking dun rsident se trouve dans limmeuble du rsident}

1.2 Prsentation gnrale dUML

1.2.4 Prsentation gnrale des diagrammes

Chapitre 1. Concepts de lapproche objet et prsentation dUML 2

Consulter catalogue Internaute Cas dutilisation Commander catalogue

Figure 1.5 Exemple de diagramme des cas dutilisation

1.2 Prsentation gnrale dUML

Client numClient nomClient +crer( ) +consulter( ) commander

Catalogue dateCatalogue +crer( ) +consulter( )

Formation attributs codeFormation intitulFormation descriptionFormation +ajouterFormation( ) +consulterFormation( )

Figure 1.6 Exemple de diagramme de classe

: Internaute consulterCatalogue( ) loop Consultation thme consulterFormation( )

change de messages entre objets

Figure 1.7 Exemple de diagramme de classe

Chapitre 1. Concepts de lapproche objet et prsentation dUML 2

1.2.5 Schma densemble des treize diagrammes dUML 2

1.2 Prsentation gnrale dUML

Vues globales ou spcialises

(tats dobjet et temps)

Architecture technique DCP

(dploiement des composants techniques)

Description des lments de la modlisation DPA