uml 2 analyse et conception (dunod)

UML 2ANALYSE ET CONCEPTIONAlgeria-Educ.comMise en uvre guide avec tudes de cas

TUDES

DVELOPPEMENT

Joseph Gabay David Gabay

ANALYSE ET CONCEPTION

UML 2Mise en uvre guide avec tudes de cas Joseph GabayDirecteur de projet informatique au CNRS Charg de cours luniversit de Paris-Dauphine

David GabayChef 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, 2008ISBN 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

V

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 mthodesUML 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].

X


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 louvrageNotre 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 louvrageLouvrage 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

RemerciementsQuil 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.

1Concepts de lapproche objet et prsentation dUML 2

1.1 CONCEPTS DE LAPPROCHE OBJETAujourdhui 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.

2

Chapitre 1. Concepts de lapproche objet et prsentation dUML 2

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

1.1.1 Objet et classeConcept dobjetUn 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

3

Un objet est une instance dune et une seule classe. Une classe abstraite est une classe qui na pas dinstance. Les concepts de classe et dobjet sont interdpendants.

Exemple Considrons la classe Employ qui reprsente lensemble des employs dune 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 interfacePar 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 classesLassociation 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.

4


CLASSE N

TraitementsAccs 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 classeLa 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 PolymorphismeLe 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

5

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 PersistanceLa 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.

6


1.1.7 Avantages du dveloppement laide des langages objetPar 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 DUML1.2.1 HistoriqueRegardons tout dabord ce qui sest pass au dbut des annes 90. Par rapport la cinquantaine de mthodes danalyse et de conception objet qui existaient au dbut des annes 90, seulement trois dentre elles se sont dtaches nettement au bout de quelques annes. En effet, la volont de converger vers une mthode unifie tait dj bien relle et cest pour cette raison que les mthodes OMT, BOOCH et OOSE se sont dmarques des autres. OMT (Object Modeling Technique) de James Rumbaugh et BOOCH de Grady Booch ont t les deux mthodes les plus diffuses en France durant les annes 90. Par ailleurs, OOSE de Ivar Jacobson sest aussi impose dans le monde objet pour la partie formalisation des besoins.

1.2 Prsentation gnrale dUML

7

Pour aller plus loin dans le rapprochement, James Rumbaugh et Grady Booch se sont retrouvs au sein de la socit Rational Software et ont t ensuite rejoints par Ivar Jacobson en se donnant comme objectif de fusionner leur mthode et crer UML (Unified Methode Language). Il est important de noter que contrairement ce qui avait t envisag au dpart, le processus de dveloppement a t sorti du champ couvert par le projet de norme. UML est donc une norme du langage de modlisation objet qui a t publie, dans sa premire version, en novembre 1997 par lOMG (Object Management Group), instance de normalisation internationale du domaine de lobjet. En quelques annes, UML sest impose comme standard utiliser en tant que langage de modlisation objet. Aujourdhui, en cette fin de la premire dcennie des annes 2000, nous avons dj une dizaine dannes de recul sur lenseignement et la pratique dUML en 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 prsentationNous 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.

8


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 gnralesAfin 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-modleLe 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) ;


9

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.

StrotypeUn 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 marqueUML 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. ProfilAfin 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


NoteUne 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

ContrainteUne 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 diagrammesUML 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 2Afin 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

2Les 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 ObjetNous 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)

ExempleLa 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 caractristiquesUn 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 oprationClasseUne 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

AttributUn 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.

OprationUne 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 oprationsChaque 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 contraintesLien et associationUn 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 dassociationLe 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

MultiplicitLa 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

NavigabilitLa 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.

A

B

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

A

B

Navigabilit unidirectionnelle de B vers A. Navigabilit de A vers B

A

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

ContraintesDautres 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-associationUne 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 classesAgrgationLagrgation 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

1 En-tte

1..* Lignes commandes

Figure 2.20 Exemple dune relation de composition

Commande

En-tte

1

Lignes commandes 1..*

Figure 2.21 Exemple de la seconde forme de reprsentation de la relation de composition

30


2.1.5 Association qualifie, dpendance et classe dinterfaceQualificationLa 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

1

contenir

1 Rpertoire nom de fichier

1 Fichier

Figure 2.22 Formalisme et exemple dassociation qualifie

DpendanceLa 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

InterfaceUne 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 spcialisationLa gnralisation/spcialisation et lhritage simpleLa 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 abstraiteUne 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 recouvrementPar 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 classeLajout 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 multipleDans 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 propritsVhicule

Vhicule terrestre

Vhicule marin

Auto

Vhicule amphibie

Bateau

Figure 2.29 Exemple de relation dhritage multiple

36


2.1.7 Strotype de classeUML 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 ExercicesNous 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

comprendre1..*

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 : DATE1..*

Agence code : nombre intitul : texte date cration : DATE date fermeture : DATE crer ( ) supprimer ( ) modifier ( ) visualiser ( ) imprimer ( ) rattacher_personnel ( ) dtacher_personnel ( )

appartenir1

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 don