Cours-UML

5/24/2018 Cours-UML

1/178

UML 2dition 2007-2008

Laurent AUDIBERT

Institut Universitaire de Technologie de Villetaneuse Dpartement InformatiqueAvenue Jean-Baptiste Clment93430 VilletaneuseAdresse lectronique : laurent[dot]audibert[at]iutv[dot]univ-paris13[dot]fr

Adresse du document :http :

//www-lipn.univ-paris13.fr

/audibert

/pages

/enseignement

/cours.htm

5/24/2018 Cours-UML

2/178

2 UML 2 Laurent Audibert http://laurent-audibert.developpez.com/Cours-UML/

5/24/2018 Cours-UML

3/178

Avant-propos

Les techniques de programmation nont cess de progresser depuis lpoque de la program-mation en langage binaire (cartes perfores, switch) nos jours. Cette volution a toujours tdicte par le besoin de concevoir et de maintenir des applications toujours plus complexes.

La programmation par cartes perfores, switch ou cblage (de 1800 1940) a ainsi faitplace des techniques plus volues, comme lassembleur (1947), avec larrive de lordinateurlectronique n des besoins de la guerre. Des langages plus volus ont ensuite vu le jour commeFortran en 1956 ou Cobol en 1959. Jusque l, les techniques de programmation taient basessur le branchement conditionnel et inconditionnel (goto) rendant les programmes importantsextrmement difficiles dvelopper, matriser et maintenir.

La programmation structure (Pascal en 1970, C en 1972, Modula et Ada en 1979, . . .) a alorsvu le jour et permis de dvelopper et de maintenir des applications toujours plus ambitieuses.Lalgorithmique ne se suffisant plus elle seule la fin des annes 1970, le gnie logiciel estvenu placer la mthodologie au cur du dveloppement logiciel. Des mthodes comme Merise(1978) se sont alors imposes.

La taille des applications ne cessant de crotre, la programmation structure a galementrencontr ses limites, faisant alors place la programmation oriente objet (Simula 67 en 1967,Smalltalk en 1976, C++ en 1982, Java en 1995, . . .). La technologie objet est donc la consquenceultime de la modularisation dicte par la matrise de la conception et de la maintenance dap-plications toujours plus complexes. Cette nouvelle technique de programmation a ncessit laconception de nouvelles mthodes de modlisation.

UML (Unified Modeling Languageen anglais, soit langage de modlisation objet unifi) estn de la fusion des trois mthodes qui simposaient dans le domaine de la modlisation objetau milieu des annes 1990 : OMT, Booch et OOSE. Dimportants acteurs industriels (IBM,Microsoft, Oracle, DEC, HP, Rational, Unisys etc.) sassocient alors leffort et proposent UML1.0 lOMG (Object Management Group) qui laccepte en novembre 1997 dans sa version 1.1.La version dUML en cours en 2008 est UML 2.1.1 qui simpose plus que jamais en tant que

langage de modlisation standardis pour la modlisation des logiciels.CedocumentconstituelesupportducoursdUML2dispensauxtudiantsdudpartementdinformatique de linstitut universitaire de technologie (IUT) de Villetaneuse en semestredcal.

Ce support a t ralis en utilisant les ouvrages cits en bibliographie. Il est en partie bassur le livre de Charroux, Osmani et Thierry-Mieg (2005) qui constitue une bonne introductionau langage UML. Aomar Osmani est lorigine du cours dUML dans notre IUT.

Rumbaugh, Jacobson et Booch (2004), Booch, Rumbaugh et Jacobson (2003), Barbier (2005)Roques et Valle (2003) et Muller et Gaertner (2000) ont galement t largement utiliss.Rumbaughet al.. (2004) est un ouvrage de rfrence assez complet et contient un dictionnairedtaill de la terminologie UML 2.0. Boochet al.. (2003), galement crit par les crateurs du

langage UML, est un guide dapprentissage compltant bien le premier ouvrage. Muller et

3

5/24/2018 Cours-UML

4/178

Gaertner (2000) est un cours dUML 2.0 bien expliqu et plus complet et dtaill que Charrouxet al.. (2005) mais, en contrepartie, moins accessible. Barbier (2005) constitue une approchepratique et critique dUML trs intressante. Roques (2006b) constitue une excellente approcheconcrte dUML comportant des exercices corrigs de trs bonne facture que nous reprenons

parfois dans les travaux dirigs de ce cours. Pascal Roques est probablement lun des auteursles plus prolifique (Roques, 2002 ; Roques & Valle, 2003 ; Roques, 2006a ; Roques, 2006b) etcomptant concernant la mise en uvre dUML.

Agrable lire, Volle (2006) sintresse la place de linformatique dans notre socit et plusparticulirement dans lentreprise.

Enfin, diverses sources trouves sur Internet, inpuisable source dinformation en perptuelrenouvellement, mont galement t dun grand secours. Parmi ces dernires, certaines sontincontournables, comme le cours de Piechocki (n.d.) ou encore le site Developpez.com (n.d.).


5/24/2018 Cours-UML

5/178

Table des matires

1 Introduction la modlisation objet 111.1 Le gnie logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.1.1 Linformatisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.1.2 Les logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.1.3 Le gnie logiciel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.1.4 Notion de qualit pour un logiciel . . . . . . . . . . . . . . . . . . . . . . . 13

1.2 Modlisation, cycles de vie et mthodes . . . . . . . . . . . . . . . . . . . . . . . . 131.2.1 Pourquoi et comment modliser? . . . . . . . . . . . . . . . . . . . . . . . 131.2.2 Le cycle de vie dun logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.2.3 Modles de cycles de vie dun logiciel . . . . . . . . . . . . . . . . . . . . . 161.2.4 Mthodes danalyse et de conception . . . . . . . . . . . . . . . . . . . . . 18

1.3 De la programmation structure lapproche oriente objet. . . . . . . . . . . . . 191.3.1 Mthodes fonctionnelles ou structures . . . . . . . . . . . . . . . . . . . . 191.3.2 Lapproche oriente objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.3.3 Approche fonctionnelle vs. approche objet . . . . . . . . . . . . . . . . . . 201.3.4 Concepts importants de lapproche objet . . . . . . . . . . . . . . . . . . . 211.3.5 Historique la programmation par objets . . . . . . . . . . . . . . . . . . . . 22

1.4 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.4.2 Histoire des modlisations par objets . . . . . . . . . . . . . . . . . . . . . 231.4.3 UML en uvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.4.4 Comment prsenter un modle UML?. . . . . . . . . . . . . . . . . . . . . 25

1.5 Travaux Dirigs Introduction la modlisation objet . . . . . . . . . . . . . . . 271.5.1 Objectifs et mise en situation . . . . . . . . . . . . . . . . . . . . . . . . . . 271.5.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

1.5.3 Conception avec une approche structure . . . . . . . . . . . . . . . . . . . 271.5.4 Conception avec une approche objet . . . . . . . . . . . . . . . . . . . . . . 281.5.5 Maintenance volutive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2 Diagramme de cas dutilisation 292.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.2 lments des diagrammes de cas dutilisation. . . . . . . . . . . . . . . . . . . . . 29

2.2.1 Acteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.2.2 Cas dutilisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.2.3 Reprsentation dun diagramme de cas dutilisation. . . . . . . . . . . . . 30

2.3 Relations dans les diagrammes de cas dutilisation . . . . . . . . . . . . . . . . . . 31

2.3.1 Relations entre acteurs et cas dutilisation . . . . . . . . . . . . . . . . . . . 31

5

5/24/2018 Cours-UML

6/178

TABLE DES MATIRES

2.3.2 Relations entre cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . 322.3.3 Relations entre acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.4 Notions gnrales du langage UML . . . . . . . . . . . . . . . . . . . . . . . . . . 342.4.1 Paquetage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.4.2 Espace de noms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.4.3 Classeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.4.4 Strotype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.4.5 Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.5 Modlisation des besoins avec UML . . . . . . . . . . . . . . . . . . . . . . . . . . 362.5.1 Comment identifier les acteurs ? . . . . . . . . . . . . . . . . . . . . . . . . 362.5.2 Comment recenser les cas dutilisation ? . . . . . . . . . . . . . . . . . . . . 372.5.3 Description textuelle des cas dutilisation . . . . . . . . . . . . . . . . . . . 382.5.4 Remarques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.6 Travaux Dirigs Diagramme de cas dutilisation . . . . . . . . . . . . . . . . . . 412.6.1 Identification des acteurs et de cas dutilisation simples. . . . . . . . . . . 412.6.2 Caisse enregistreuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.6.3 La bibliothque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3 Diagramme de classes 453.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.2 Les classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.2.1 Notions de classe et dinstance de classe. . . . . . . . . . . . . . . . . . . . 453.2.2 Caractristiques dune classe . . . . . . . . . . . . . . . . . . . . . . . . . . 463.2.3 Reprsentation graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.2.4 Encapsulation, visibilit, interface . . . . . . . . . . . . . . . . . . . . . . . 473.2.5 Nom dune classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.2.6 Les attributs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.2.7 Les mthodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.2.8 Classe active. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.3 Relations entre classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.3.1 Notion dassociation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.3.2 Terminaison dassociation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.3.3 Association binaire et n-aire . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.3.4 Multiplicit ou cardinalit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.3.5 Navigabilit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.3.6 Qualification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.3.7 Classe-association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.3.8 Agrgation et composition . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.3.9 Gnralisation et Hritage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.3.10 Dpendance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.4 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.5 Diagramme dobjets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.5.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.5.2 Reprsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.5.3 Relation de dpendance dinstanciation . . . . . . . . . . . . . . . . . . . . 64

3.6 laboration et implmentation dun diagramme de classes . . . . . . . . . . . . . 643.6.1 laboration dun diagramme de classes . . . . . . . . . . . . . . . . . . . . 64

3.6.2 Implmentation en Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65


5/24/2018 Cours-UML

7/178

TABLE DES MATIRES

3.6.3 Implmentation en SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693.7 Travaux Dirigs Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . 73

3.7.1 Proprits et relations simples . . . . . . . . . . . . . . . . . . . . . . . . . 733.7.2 Identification des relations . . . . . . . . . . . . . . . . . . . . . . . . . . . 733.7.3 Interfaces/hritage multiple . . . . . . . . . . . . . . . . . . . . . . . . . . 743.7.4 Classes /Objets /Implmentation. . . . . . . . . . . . . . . . . . . . . . . . 743.7.5 Systme de rservation de vols :Modle du domaine . . . . . . . . . . . . . 753.7.6 La bibliothque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4 Object constraint langage(OCL) 774.1 Expression des contraintes en UML. . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.1.2 criture des contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.1.3 Reprsentation des contraintes et contraintes prdfinies . . . . . . . . . . 79

4.2 Intrt dOCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.2.1 OCL Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.2.2 Illustration par lexemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.3 Typologie des contraintes OCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.3.1 Diagramme support des exemples illustratifs. . . . . . . . . . . . . . . . . 824.3.2 Contexte (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834.3.3 Invariants (inv) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834.3.4 Prconditions et postconditions (pre,post) . . . . . . . . . . . . . . . . . . . 844.3.5 Rsultat dune mthode (body) . . . . . . . . . . . . . . . . . . . . . . . . . 854.3.6 Dfinition dattributs et de mthodes (defetlet. . .in) . . . . . . . . . . . . . 85

4.3.7 Initialisation (init) et volution des attributs (derive) . . . . . . . . . . . . . 864.4 Types et oprations utilisables dans les expressions OCL . . . . . . . . . . . . . . 87

4.4.1 Types et oprateurs prdfinis . . . . . . . . . . . . . . . . . . . . . . . . . 874.4.2 Types du modle UML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874.4.3 OCL est un langage typ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884.4.4 Collections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

4.5 Accs aux caractristiques et aux objets . . . . . . . . . . . . . . . . . . . . . . . . 884.5.1 Accs aux attributs et aux oprations (self) . . . . . . . . . . . . . . . . . . 884.5.2 Navigation via une association . . . . . . . . . . . . . . . . . . . . . . . . . 894.5.3 Navigation via une association qualifie. . . . . . . . . . . . . . . . . . . . 89

4.5.4 Navigation vers une classe association. . . . . . . . . . . . . . . . . . . . . 904.5.5 Navigation depuis une classe association . . . . . . . . . . . . . . . . . . . 904.5.6 Accder une caractristique redfinie (oclAsType()). . . . . . . . . . . . . 914.5.7 Oprations prdfinies sur tous les objets . . . . . . . . . . . . . . . . . . . 914.5.8 Opration sur les classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

4.6 Oprations sur les collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924.6.1 Introduction : ., ->, : : etself . . . . . . . . . . . . . . . . . . . . . . . 924.6.2 Oprations de base sur les collections . . . . . . . . . . . . . . . . . . . . . 934.6.3 Opration sur les lments dune collection . . . . . . . . . . . . . . . . . . 944.6.4 Rgles de prcdence des oprateurs. . . . . . . . . . . . . . . . . . . . . . 96

4.7 Exemples de contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

UML 2 Laurent Audibert http://laurent-audibert.developpez.com/Cours-UML/ 7

5/24/2018 Cours-UML

8/178

TABLE DES MATIRES

5 Diagramme dtats-transitions 995.1 Introduction au formalisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

5.1.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 995.1.2 Notion dautomate tats finis . . . . . . . . . . . . . . . . . . . . . . . . . 99

5.1.3 Diagrammes dtats-transitions. . . . . . . . . . . . . . . . . . . . . . . . . 1005.2 tat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

5.2.1 Les deux acceptions du termetat . . . . . . . . . . . . . . . . . . . . . . . 1005.2.2 tat initial et final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

5.3 vnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025.3.1 Notion dvnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025.3.2 vnement de type signal (signal) . . . . . . . . . . . . . . . . . . . . . . . 1025.3.3 vnement dappel (call). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025.3.4 vnement de changement (change) . . . . . . . . . . . . . . . . . . . . . . 1035.3.5 vnement temporel (afterouwhen) . . . . . . . . . . . . . . . . . . . . . . 103

5.4 Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035.4.1 Dfinition et syntaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035.4.2 Condition de garde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1045.4.3 Effet dune transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1045.4.4 Transition externe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1045.4.5 Transition dachvement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1045.4.6 Transition interne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

5.5 Point de choix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1055.5.1 Point de jonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1055.5.2 Point de dcision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

5.6 tats composites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

5.6.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1075.6.2 Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1085.6.3 tat historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1085.6.4 Interface : les points de connexion . . . . . . . . . . . . . . . . . . . . . . . 1105.6.5 Concurrence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

5.7 Travaux Dirigs Diagramme dtats-transitions . . . . . . . . . . . . . . . . . . 1135.7.1 Porte de garage motorise enroulement . . . . . . . . . . . . . . . . . . . 1135.7.2 Montre digitale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

6 Diagramme dactivits 1176.1 Introduction au formalisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

6.1.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1176.1.2 Utilisation courante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1176.2 Activit et Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

6.2.1 Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1186.2.2 Activit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1196.2.3 Groupe dactivits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1196.2.4 Nud dactivit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1196.2.5 Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

6.3 Nud excutable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1216.3.1 Nud daction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1216.3.2 Nud dactivit structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

6.4 Nud de contrle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122


5/24/2018 Cours-UML

9/178

TABLE DES MATIRES

6.4.1 Nud initial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1236.4.2 Nud final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1236.4.3 Nud de dcision et de fusion . . . . . . . . . . . . . . . . . . . . . . . . . 1236.4.4 Nud de bifurcation et dunion . . . . . . . . . . . . . . . . . . . . . . . . 124

6.5 Nud dobjet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1256.5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1256.5.2 Pin dentre ou de sortie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1256.5.3 Pin de valeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1256.5.4 Flot dobjet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1256.5.5 Nud tampon central . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1266.5.6 Nud de stockage des donnes . . . . . . . . . . . . . . . . . . . . . . . . 126

6.6 Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1276.7 Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1276.8 Travaux Dirigs Diagramme dactivits . . . . . . . . . . . . . . . . . . . . . . . 131

6.8.1 Mousse au chocolat (question du contrle du 8 janvier 2007) . . . . . . . . 1316.8.2 Modlisation dune opration dinsertion dans un tableau tri . . . . . . . 1316.8.3 Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1316.8.4 Documentation dun cas dutilisation . . . . . . . . . . . . . . . . . . . . . 131

7 Diagrammes dinteraction 1357.1 Prsentation du formalisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

7.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1357.1.2 Classeur structur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1357.1.3 Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1367.1.4 Interactions et lignes de vie . . . . . . . . . . . . . . . . . . . . . . . . . . . 1377.1.5 Reprsentation gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

7.2 Diagramme de communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1387.2.1 Reprsentation des lignes de vie . . . . . . . . . . . . . . . . . . . . . . . . 1397.2.2 Reprsentation des connecteurs. . . . . . . . . . . . . . . . . . . . . . . . . 1397.2.3 Reprsentation des messages . . . . . . . . . . . . . . . . . . . . . . . . . . 139

7.3 Diagramme de squence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1397.3.1 Reprsentation des lignes de vie . . . . . . . . . . . . . . . . . . . . . . . . 1407.3.2 Reprsentation des messages . . . . . . . . . . . . . . . . . . . . . . . . . . 1407.3.3 Fragments dinteraction combins . . . . . . . . . . . . . . . . . . . . . . . 1447.3.4 Utilisation dinteraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

7.4 Travaux Dirigs Diagramme dinteraction. . . . . . . . . . . . . . . . . . . . . . 147

7.4.1 Diagramme de communication : syntaxe des messages . . . . . . . . . . . 1477.4.2 Nono le petit robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1477.4.3 Types de messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1477.4.4 La bibliothque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1487.4.5 Distributeur de boisson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

8 Diagrammes de composants et de dploiement 1518.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1518.2 Diagrammes de composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

8.2.1 Pourquoi des composants ? . . . . . . . . . . . . . . . . . . . . . . . . . . . 1518.2.2 Notion de composant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

8.2.3 Notion de port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152


5/24/2018 Cours-UML

10/178

TABLE DES MATIRES

8.2.4 Diagramme de composants . . . . . . . . . . . . . . . . . . . . . . . . . . . 1528.3 Diagramme de dploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

8.3.1 Objectif du diagramme de dploiement . . . . . . . . . . . . . . . . . . . . 1558.3.2 Reprsentation des nuds. . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

8.3.3 Notion dartefact (artifact) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1558.3.4 Diagramme de dploiement. . . . . . . . . . . . . . . . . . . . . . . . . . . 157

9 Mise en uvre dUML 1599.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

9.1.1 UML nest pas une mthode . . . . . . . . . . . . . . . . . . . . . . . . . . 1599.1.2 Une mthode simple et gnrique . . . . . . . . . . . . . . . . . . . . . . . 160

9.2 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1609.2.1 Diagramme de cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . 1609.2.2 Diagrammes de squence systme . . . . . . . . . . . . . . . . . . . . . . . 1619.2.3 Maquette de lIHM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

9.3 Phases danalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1629.3.1 Modle du domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1629.3.2 Diagramme de classes participantes . . . . . . . . . . . . . . . . . . . . . . 1639.3.3 Diagrammes dactivits de navigation . . . . . . . . . . . . . . . . . . . . . 165

9.4 Phase de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1669.4.1 Diagrammes dinteraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1669.4.2 Diagramme de classes de conception . . . . . . . . . . . . . . . . . . . . . 168

Bibliographie 171

Index 173


5/24/2018 Cours-UML

11/178

Chapitre 1

Introduction la modlisation objet

1.1 Le gnie logiciel

1.1.1 Linformatisation

Linformatisation est le phnomne le plus important de notre poque. Elle simmisce main-tenant dans la pluspart des objets de la vie courante et ce, que ce soit dans lobjet proprementdit1 ,ou bien dans le processus de conception ou de fabrication de cet objet.

Actuellement, linformatique est au cur de toutes les grandes entreprises. Le systmedinformation dune entreprise est compos de matriels et de logiciels. Plus prcisment, lesinvestissements dans ce systme dinformation se rparatissent gnralement de la maniresuivante : 20% pour le matriel et 80% pour le logiciel. En effet, depuis quelques annes, lafabrication du matriel est assure par quelques fabricants seulement. Ce matriel est relative-ment fiable et le march est standardis. Lesproblmes lis linformatique sontessentiellement

des problmes de logiciel.

1.1.2 Les logiciels

Un logiciel ou une application est un ensemble de programmes, qui permet un ordinateurou un systme informatique dassurer une tche ou une fonction en particulier (exemple :logiciel de comptabilit, logiciel de gestion des prts).

Les logiciels, suivant leur taille, peuvent tre dvelopps par une personne seule, une petitequipe, ou un ensemble dquipes coordonnes. Le dveloppement de grands logiciels parde grandes quipes pose dimportants problmes de conception et de coordination. Or, ledveloppement dun logiciel est une phase absolument cruciale qui monopolise lessentiel du

cot dun produit2 et conditionne sa russite et sa prennit.En 1995, une tude du Standish Group dressait un tableau accablant de la conduite des

projets informatiques. Reposant sur un chantillon reprsentatif de 365 entreprises, totalisant8380 applications, cette tude tablissait que :

16, 2% seulement des projets taient conformes aux prvisions initiales, 52, 7% avaient subi des dpassements en cot et dlai dun facteur 2 3 avec diminution

du nombre des fonctions offertes,1 Par exemple, aujourdhui, 90% des nouvelles fonctionnalits des automobiles sont apportes par llectronique

et linformatique embarques. Il y a, ou aura terme, du logiciel partout : ampoules lectriques, four micro ondes,tissus des vtements, stylos, livres, etc.

2 Comparativement sa production, le cot du dveloppement dun logiciel est extrmement important. Nous

verrons par la suite que la maintenance cote galement trs cher.

11

5/24/2018 Cours-UML

12/178

CHAPITRE 1. INTRODUCTION LA MODLISATION OBJET

31, 1% ont t purement abandonns durant leur dveloppement.Pour les grandes entreprises (qui lancent proportionnellement davantage de gros projets), letaux de succs est de 9% seulement, 37% des projets sont arrts en cours de ralisation, 50%aboutissent hors dlai et hors budget.

Lexamen des causes de succs et dchec est instructif : la plupart des checs proviennentnon de linformatique, mais de la matrise douvrage3 (i.e.le client).

Pour ces raisons, le dveloppement de logiciels dans un contexte professionnel suit souventdes rgles strictes encadrant la conception et permettant le travail en groupe et la maintenance4

du code. Ainsi, une nouvelle discipline est ne : le gnie logiciel.

1.1.3 Le gnie logiciel

Le gnie logiciel est un domaine de recherche qui a t dfini (fait rare) du 7 au 11 octobre1968, Garmisch-Partenkirchen, sous le parrainage de lOTAN. Il a pour objectif de rpondre un problme qui snonait en deux constatations : dune part le logiciel ntait pas fiable,

dautre part, il tait incroyablement difficile de raliser dans des dlais prvus des logicielssatisfaisant leur cahier des charges.

Lobjectif du gnie logiciel est doptimiser le cot de dveloppement du logiciel. Limpor-tance dune approche mthodologique sest impose la suite de la crise de lindustrie dulogiciel la fin des annes 1970. Cette crise de lindustrie du logiciel tait principalement due :

laugmentation des cots ; les difficults de maintenance et dvolution ; la non fiabilit ; le non respect des spcifications ; le non respect des dlais.La maintenance est devenue une facette trs importante du cycle de vie dun logiciel. En

effet, une enqute effectue aux USA en 1986 auprs de 55 entreprises rvle que 53% du budgettotal dun logiciel est affect la maintenance. Ce cot est rparti comme suit :

34% maintenance volutive (modification des spcifications initiales) ; 10% maintenance adaptative (nouvel environnement, nouveaux utilisateurs) ; 17% maintenance corrective (correction des bogues) ; 16% maintenance perfective (amliorer les performance sans changer les spcifications) ; 6% assistance aux utilisateurs ; 6% contrle qualit; 7% organisation/suivi; 4% divers.Pourapporterunerponsetouscesproblmes,legnielogicielsintresseparticulirement

la manire dont le code source dun logiciel est spcifi puis produit. Ainsi, le gnie logicieltouche au cycle de vie des logiciels :

lanalyse du besoin, llaboration des spcifications, la conceptualisation, le dveloppement, la phase de test,

3 c.f. section1.2.1 Matrise douvrage et matrise duvre pour une dfinition de ce terme.4 Souvent, les personnes qui doivent oprer des modifications ultrieures dans le code ne sont plus les personnes

qui lont dvelopp.


5/24/2018 Cours-UML

13/178

1.2. MODLISATION, CYCLES DE VIE ET MTHODES

la maintenance.Les projets relatifs lingnierie logicielle sont gnralement de grande envergure et d-

passent souvent les 10000 lignes de code. Cest pourquoi ces projets ncessitent une quipe dedveloppement bien structure. La gestion de projet se retrouve naturellement intimement lie

au gnie logiciel.

1.1.4 Notion de qualit pour un logiciel

En gnie logiciel, divers travaux ont men la dfinition de la qualit du logiciel en termesde facteurs, quidpendent, entre autres, du domainede lapplication et desoutilsutiliss. Parmices derniers nous pouvons citer :

Validit : aptitude dun produit logiciel remplir exactement ses fonctions, dfinies par lecahier des charges et les spcifications.

Fiabilit ou robustesse : aptitude dun produit logiciel fonctionner dans des conditionsanor-

males.Extensibilit (maintenance) : facilit avec laquelle un logiciel se prte sa maintenance, cest--dire une modification ou une extension des fonctions qui lui sont demandes.

Rutilisabilit : aptitude dun logiciel tre rutilis, en tout ou en partie, dans de nouvellesapplications.

Compatibilit : facilit avec laquelle un logiciel peut tre combin avec dautres logiciels.

Efficacit : Utilisation optimales des ressources matrielles.

Portabilit : facilit avec laquelle un logiciel peut tre transfr sous diffrents environnementsmatriels et logiciels.

Vrifiabilit : facilit de prparation des procdures de test.

Intgrit : aptitude dun logiciel protger son code et ses donnes contre des accs nonautoriss.

Facilit demploi : facilit dapprentissage, dutilisation, de prparation des donnes, dinter-prtation des erreurs et de rattrapage en cas derreur dutilisation.

Ces facteurs sont parfois contradictoires, le choix des compromis doit seffectuer en fonction ducontexte.

1.2 Modlisation, cycles de vie et mthodes

1.2.1 Pourquoi et comment modliser ?Quest-ce quun modle ?

Un modle est une reprsentation abstraite et simplifie (i.e. qui exclut certains dtails), duneentit (phnomne, processus, systme, etc.) du monde rel en vue de le dcrire, de lexpliquerou de le prvoir. Modle est synonyme de thorie, mais avec une connotation pratique : unmodle, cest une thorie oriente vers laction quelle doit servir.

Concrtement, un modle permet de rduire la complexit dun phnomne en liminantles dtails qui ninfluencent pas son comportement de manire significative. Il reflte ce que leconcepteur croit important pour la comprhension et la prdiction du phnomne modlis.Les limites du phnomne modlis dpendant des objectifs du modle.

Voici quelques exemples de modles :


5/24/2018 Cours-UML

14/178


Modle mtorologique partir dedonnes dobservation (satellite, . . .), ilpermet de prvoirles conditions climatiques pour les jours venir.

Modle conomique peut par exemple permettre de simuler lvolution de cours boursiersen fonction dhypothses macro-conomiques (volution du chmage, taux de croissance,. . . ) .

Modle dmographique dfinit la composition dun panel dune population et son com-portement, dans le but de fiabiliser des tudes statistiques, daugmenter limpact dedmarches commerciales, etc.

Plans Les plans sont des modles qui donnent une vue densemble du systme concern.Par exemple, dans le btiment, pour la construction dun immeuble, il faut pralablementlaborer de nombreux plans : plans dimplantation du btiment dans son environnement ; plans gnraux du btiment et de sa structure ; plans dtailles des diffrents locaux, bureaux, appartements, . . .

plans des cblages lectriques ; plans dcoulements des eaux, etc.

Les trois premiers exemples sont des modles que lon qualifie de prdictifs. Le dernier,plus conceptuel, possde diffrents niveaux de vues comme la pluspart des modles en gnielogiciel.

Pourquoi modliser ?

Modliser un systme avant sa ralisation permet de mieux comprendre le fonctionnementdu systme. Cest galement un bon moyen de matriser sa complexit et dassurer sa cohrence.Un modle est un langage commun, prcis, qui est connu par tous les membres de lquipe et il

estdonc,cetitre,unvecteurprivilgipourcommuniquer.Cettecommunicationestessentiellepour aboutir une comprhension commune aux diffrentes parties prenantes (notammententre la matrise douvrage et la matrise duvre informatique) et prcise dun problmedonn.

Dans le domaine de lingnierie du logiciel, le modle permet de mieux rpartir les tcheset dautomatiser certaines dentre elles. Cest galement un facteur de rduction des cotset des dlais. Par exemple, les plateformes de modlisation savent maintenant exploiter lesmodles pour faire de la gnration de code (au moins au niveau du squelette) voire des aller-retours entre le code et le modle sans perte dinformation. Le modle est enfin indispensablepour assurer un bon niveau de qualit et une maintenance efficace. En effet, une fois mise enproduction, lapplication va devoir tre maintenue, probablement par une autre quipe et, qui

plus est, pas ncessairement de la mme socit que celle ayant cre lapplication.Le choix du modle a donc une influence capitale sur les solutions obtenues. Les systmesnon-triviaux sont mieux modliss par un ensemble de modles indpendants. Selon les mo-dles employs, la dmarche de modlisation nest pas la mme.

Qui doit modliser ?

La modlisation est souvent faite par la matrise duvre informatique (MOE). Cest mal-encontreux, car les priorits de la MOE rsident dans le fonctionnement de la plate-formeinformatique et non dans les processus de lentreprise.

Il est prfrable que la modlisation soit ralise par la matrise douvrage (MOA) de sorte

que le mtier soit matre de ses propres concepts. La MOE doit intervenir dans le modle


5/24/2018 Cours-UML

15/178


lorsque, aprs avoir dfini les concepts du mtier, on doit introduire les contraintes propres la plate-forme informatique.

Il est vrai que certains mtiers, dont les priorits sont oprationnelles, ne disposent pas tou-jours de la capacit dabstraction et de la rigueur conceptuelle ncessaires la formalisation. La

professionnalisation de la MOA a pour but de les doter de ces comptences. Cette professionna-lisation rside essentiellement dans laptitude modliser le systme dinformation du mtier :le matre mot est modlisation. Lorsque le modle du systme dinformation est de bonne qualit,sobre, clair, stable, la matrise duvre peut travailler dans de bonnes conditions. Lorsque cetteprofessionnalisation a lieu, elle modifie les rapports avec linformatique et dplace la frontiredes responsabilits, ce qui contrarie parfois les informaticiens dans un premier temps, avantquils nen voient apparatre les bnfices.

Matrise douvrage et matrise duvre

Matre douvrage (MOA) : Le MOA est une personne morale (entreprise, direction etc.), une

entit de lorganisation. Ce nest jamais une personne.Matre duvre (MOE) : Le MOE est une personne morale (entreprise, direction etc.) garante

de la bonne ralisation technique des solutions. Il a, lors de la conception du SI, un devoirdeconseilvis--visduMOA,carleSIdoittirerlemeilleurpartidespossibilitstechniques.

Le MOA est client du MOE qui il passe commande dun produit ncessaire son activit.Le MOE fournit ce produit; soit il le ralise lui-mme, soit il passe commande un ou

plusieurs fournisseurs ( entreprises ) qui laborent le produit sous sa direction.La relation MOA et MOE est dfinie par un contrat qui prcise leurs engagements mutuels.Lorsque le produit est compliqu, il peut tre ncessaire de faire appel plusieurs four-

nisseurs. Le MOE assure leur coordination ; il veille la cohrence des fournitures et leur

compatibilit. Il coordonne laction des fournisseurs en contrlant la qualit technique, en as-surant le respect des dlais fixs par le MOA et en minimisant les risques.

Le MOE est responsable de la qualit technique de la solution. Il doit, avant toute livraisonau MOA, procder aux vrifications ncessaires ( recette usine ).

1.2.2 Le cycle de vie dun logiciel

Lecycle de vie dun logiciel (en anglaissoftware lifecycle), dsigne toutes les tapes du dve-loppement dun logiciel, de sa conception sa disparition. Lobjectif dun tel dcoupage estde permettre de dfinir des jalons intermdiaires permettant la validation du dveloppementlogiciel, cest--dire la conformit du logiciel avec les besoins exprims, et la vrification du

processus de dveloppement, cest--dire ladquation des mthodes mises en uvre.Lorigine de ce dcoupage provient du constat que les erreurs ont un cot dautant plus

lev quelles sont dtectes tardivement dans le processus de ralisation. Le cycle de viepermet de dtecter les erreurs au plus tt et ainsi de matriser la qualit du logiciel, les dlaisde sa ralisation et les cots associs.

Le cycle de vie du logiciel comprend gnralement au minimum les tapes suivantes :

Dfinition des objectifs Cet tape consiste dfinir la finalit du projet et son inscriptiondans une stratgie globale.

Analyse des besoins et faisabilit cest--dire lexpression, le recueil et la formalisation desbesoins du demandeur (le client) et de lensemble des contraintes, puis lestimation de la

faisabilit de ces besoins.


5/24/2018 Cours-UML

16/178


Spcifications ou conception gnrale Il sagit de llaboration des spcifications de larchi-tecture gnrale du logiciel.

Conception dtaille Cette tape consiste dfinir prcisment chaque sous-ensemble du

logiciel.Codage (Implmentation ou programmation) cest la traduction dans un langage de pro-grammation des fonctionnalits dfinies lors de phases de conception.

Tests unitaires Ils permettent de vrifier individuellement que chaque sous-ensemble dulogiciel est implment conformment aux spcifications.

Intgration Lobjectif est de sassurer de linterfaage des diffrents lments (modules) dulogiciel. Elle fait lobjet de tests dintgration consigns dans un document.

Qualification (ou recette) Cest--dire la vrification de la conformit du logiciel aux spcifi-cations initiales.

Documentation Elle vise produire les informations ncessaires pour lutilisation du logiciel

et pour des dveloppements ultrieurs.Mise en production Cest le dploiement sur site du logiciel.

Maintenance Elle comprend toutes les actions correctives (maintenance corrective) et volu-tives (maintenance volutive) sur le logiciel.

La squence et la prsence de chacune de ces activits dans le cycle de vie dpend du choixdun modle de cycle de vie entre le client et lquipe de dveloppement. Le cycle de vie permetde prendre en compte, en plus des aspects techniques, lorganisation et les aspects humains.

1.2.3 Modles de cycles de vie dun logiciel

Modle de cycle de vie en cascade

Lemodledecycledevieencascade(cf.figure 1.1)atmisaupointds1966,puisformalisaux alentours de 1970.

Dans ce modle le principe est trs simple : chaque phase se termine une date prcisepar la production de certains documents ou logiciels. Les rsultats sont dfinis sur la base desinteractions entre tapes, ils sont soumis une revue approfondie et on ne passe la phasesuivante que sils sont jugs satisfaisants.

Lemodleoriginalnecomportaitpasdepossibilitderetourenarrire.Celle-ciatrajouteultrieurement sur la base quune tape ne remet en cause que ltape prcdente, ce qui, dansla pratique, savre insuffisant.

Linconvnient majeur du modle de cycle de vie en cascade est que la vrification du bonfonctionnement du systme est ralise trop tardivement : lors de la phase dintgration, oupire, lors de la mise en production.

Modle de cycle de vie en V

Le modle en V (cf. figure 1.2) demeure actuellement le cycle de vie le plus connu etcertainement le plus utilis. Il sagit dun modle en cascade dans lequel le dveloppement destests et du logiciels sont effectus de manire synchrone.

Le principe de ce modle est quavec toute dcomposition doit tre dcrite la recompositionet que toute description dun composant est accompagne de tests qui permettront de sassurer

quil correspond sa description.


5/24/2018 Cours-UML

17/178


F. 1.1 Modle du cycle de vie en cascade

F. 1.2 Modle du cycle de vie en V


5/24/2018 Cours-UML

18/178


Ceci rend explicite la prparation des dernires phases (validation-vrification) par les pre-mires (construction du logiciel), et permet ainsi dviter un cueilbien connu de la spcificationdu logiciel : noncer une proprit quil est impossible de vrifier objectivement aprs la rali-sation.

Cependant, ce modle souffre toujours du problme de la vrification trop tardive du bonfonctionnement du systme.

Modle de cycle de vie en spirale

Propos par B. Boehm en 1988, ce modle est beaucoup plus gnral que le prcdent. Ilmet laccent sur lactivit danalyse des risques : chaque cycle de la spirale se droule en quatrephases :

1. dtermination, partir des rsultats des cycles prcdents, ou de lanalyse prliminairedes besoins, des objectifs du cycle, des alternatives pour les atteindre et des contraintes ;

2. analyse des risques, valuation des alternatives et, ventuellement maquettage ;3. dveloppement et vrification de la solution retenue, un modle classique (cascade ou

en V) peut tre utilis ici ;

4. revue des rsultats et vrification du cycle suivant.

Lanalyse prliminaire est affine au cours des premiers cycles. Le modle utilise des ma-quettes exploratoires pour guider la phase de conception du cycle suivant. Le dernier cycle setermine par un processus de dveloppement classique.

Modle par incrment

Dans les modles prcdents un logiciel est dcompos en composants dvelopps spar-ment et intgrs la fin du processus.Dans les modles par incrment un seul ensemble de composants est dvelopp la fois :

des incrments viennent sintgrer un noyau de logiciel dvelopp au pralable. Chaqueincrment est dvelopp selon lun des modles prcdents.

Les avantages de ce type de modle sont les suivants : chaque dveloppement est moins complexe ; les intgrations sont progressives ; il est ainsi possible de livrer et de mettre en service chaque incrment ; ilpermetunmeilleurlissagedutempsetdeleffortdedveloppementgrcelapossibilit

de recouvrement (paralllisation) des diffrentes phases.

Les risques de ce type de modle sont les suivants : remettre en cause les incrments prcdents ou pire le noyau ; ne pas pouvoir intgrer de nouveaux incrments.Les noyaux, les incrments ainsi que leurs interactions doivent donc tre spcifis globa-

lement, au dbut du projet. Les incrments doivent tre aussi indpendants que possibles,fonctionnellement mais aussi sur le plan du calendrier du dveloppement.

1.2.4 Mthodes danalyse et de conception

Les mthodes danalyse et de conception fournissent une mthodologie et des notationsstandards qui aident concevoir des logiciels de qualit. Il existe diffrentes manires pour

classer ces mthodes, dont :


5/24/2018 Cours-UML

19/178

1.3. DE LA PROGRAMMATION STRUCTURE LAPPROCHE ORIENTE OBJET

La distinction entre composition et dcomposition : Ellemetenoppositiondunepartlesm-thodes ascendantes qui consistent construire un logiciel par composition partir demodules existants et, dautre part, les mthodes descendantes qui dcomposent rcursi-vement le systme jusqu arriver des modules programmables simplement.

La distinction entre fonctionnel (dirige par le traitement) et oriente objet : Dans la strat-gie fonctionnelle (galement qualifie de structure) un systme est vu comme un en-semble hirarchique dunits en interaction, ayant chacune une fonction clairement d-finie. Les fonctions disposent dun tat local, mais le systme a un tat partag, qui estcentralis et accessible par lensemble des fonctions. Les stratgies orientes objet consi-drent quun systme est un ensemble dobjets interagissants. Chaque objet dispose dunensemble dattributs dcrivant son tat et ltat du systme est dcrit (de faon dcentra-lise) par ltat de lensemble.

1.3 De la programmation structure lapproche oriente objet

1.3.1 Mthodes fonctionnelles ou structures

F. 1.3 Reprsentation graphique dune approche fonctionnelle

Les mthodes fonctionnelles (galement qualifies de mthodes structures) trouvent leurorigine dans les langages procduraux. Elles mettent en vidence les fonctions assurer etproposent une approche hirarchique descendante et modulaire.

Ces mthodes utilisent intensivement les raffinements successifs pour produire des spci-fications dont lessentielle est sous forme de notation graphique en diagrammes de flots de

donnes. Le plus haut niveau reprsente lensemble du problme (sous forme dactivit, dedonnes ou de processus, selon la mthode). Chaque niveau est ensuite dcompos en respec-tant les entres/sorties du niveau suprieur. La dcomposition se poursuit jusqu arriver descomposants matrisables (cf. figure1.3).

Lapprochefonctionnelledissocieleproblmedelareprsentationdesdonnes,duproblmedu traitement de ces donnes. Sur la figure1.3,les donnes du problme sont reprsentes surla gauche. Des flches transversalles matrialisent la manipulation de ces donnes par des sous-fonctions. Cet accs peut-tre direct (cest parfois le cas quand les donnes sont regroupes dansune base de donnes), ou peut tre ralis par le passage de paramtre depuis le programmeprincipal.

La SADT (Structured Analysis Design Technique) est probablement la mthode danalyse

fonctionnelle et de gestion de projets la plus connue. Elle permet non seulement de dcrire les


5/24/2018 Cours-UML

20/178


tches du projet et leurs interactions, mais aussi de dcrire le systme que le projet vise tudier,crer ou modifier, en mettant notamment en vidence les parties qui constituent le systme,la finalit et le fonctionnement de chacune, ainsi que les interfaces entre ces diverses parties.Le systme ainsi modlis nest pas une simple collection dlments indpendants, mais une

organisation structure de ceux-ci dans une finalit prcise.En rsum, larchitecture du systme est dicte par la rponse au problme (i.e. la fonction

du systme).

1.3.2 Lapproche oriente objet

Lapproche oriente objet considre le logiciel comme une collection dobjets dissocis, iden-tifis et possdant des caractristiques. Une caractristique est soit un attribut (i.e.une donnecaractrisant ltat de lobjet), soit une entit comportementale de lobjet (i.e.une fonction). Lafonctionnalit du logiciel merge alors de linteraction entre les diffrents objets qui le consti-tuent. Lune des particularits de cette approche est quelle rapproche les donnes et leurs

traitements associs au sein dun unique objet.Comme nous venons de le dire, un objet est caractris par plusieurs notions :

Lidentit Lobjet possde une identit, qui permet de le distinguer des autres objets, ind-pendamment de son tat. On construit gnralement cette identit grce un identifiantdcoulant naturellement du problme (par exemple un produit pourra tre repr par uncode, une voiture par un numro de srie, etc.)

Les attributs Il sagit des donnes caractrisant lobjet. Ce sont des variables stockant desinformations sur ltat de lobjet.

Les mthodes Les mthodes dun objet caractrisent son comportement, cest--dire len-semble des actions (appeles oprations) que lobjet est mme de raliser. Ces oprationspermettent de faire ragir lobjet aux sollicitations extrieures (ou dagir sur les autres ob-

jets). De plus, les oprations sont troitement lies aux attributs, car leurs actions peuventdpendre des valeurs des attributs, ou bien les modifier.

La difficult de cette modlisation consiste crer une reprsentation abstraite, sous formedobjets, dentits ayant une existence matrielle (chien, voiture, ampoule, personne, . . .) ou

bien virtuelle (client, temps, . . .).La Conception Oriente Objet (COO) est la mthode qui conduit des architectures logi-

cielles fondes sur les objets du systme, plutt que sur la fonction quil est cens raliser.En rsum, larchitecture du systme est dicte par la structure du problme.

1.3.3 Approche fonctionnelle vs. approche objetSelon la thse de Church-Turing, tout langage de programmation non trivial quivaut une

machine de Turing. Il en rsulte que tout programme quil est possible dcrire dans un langagepourrait galement tre crit dans nimporte quel autre langage. Ainsi, tout ce que lon faitavec un langage de programmation par objets pourrait tre fait en programmation imprative.La diffrence entre une approche fonctionnelle et une approche objet nest donc pas dordrelogique, mais pratique.

Lapproche structure privilgie la fonction comme moyen dorganisation du logiciel. Cenest pas pour cette raison que lapproche objet est une approche non fonctionnelle. En effet,les mthodes dun objet sont des fonctions. Ce qui diffrencie sur le fond lapproche objet de

lapproche fonctionnelle, cest que les fonctions obtenues lissue de la mise en uvre de lune


5/24/2018 Cours-UML

21/178

1.3. DE LA PROGRAMMATION STRUCTURE LAPPROCHE ORIENTE OBJET

ou lautre mthode sont distinctes. Lapproche objet est une approche oriente donne. Danscette approche, les fonctions se dduisent dun regroupement de champs de donnes formantune entit cohrente, logique, tangible et surtout stable quant au problme trait. Lapprochestructure classique privilgie une organisation des donnes postrieure la dcouverte des

grandes, puis petites fonctions qui les dcomposent, lensemble constituant les services quirpondent aux besoins.

En approche objet, lvolution des besoins aura le plus souvent tendance se prsentercomme un changement de linteraction des objets. Sil faut apporter une modification auxdonnes, seul lobjet incrimin (encapsulant cette donne) sera modifi. Toutes les fonctions modifier sont bien identifies : elles se trouvent dans ce mme objet : ce sont ses mthodes. Dansune approche structure, lvolution des besoins entrane souvent une dgnrescence, ou uneprofonde remise en question, de la topologie typique de la figure 1.3car la dcomposition desunitsde traitement (duprogramme principal aux sous-fonctions) est directement dicte par ces

besoins. Dautre part, une modification des donnes entrane gnralement une modificationdun nombre important de fonctions parpilles et difficiles identifier dans la hirarchie decette dcomposition.

En fait, la modularit nest pas antinomique de lapproche structure. Les modules rsultantde la dcomposition objet sont tout simplement diffrents de ceux manant de lapprochestructure. Les units de traitement, et surtout leur dpendance dans la topologie de la figure1.3sont initialement bons. Cest leur rsistance au temps, contrairement aux modules objet, quiest source de problme. La structure dun logiciel issue dune approche structure est beaucoupmoins mallable, adaptable, que celle issue dune approche objet.

Ainsi la technologie objet est la consquence ultime de la modularisation du logiciel, d-marche qui vise matriser sa production et son volution. Mais malgr cette continuit logiqueles langages objet ont apport en pratique un profond changement dans lart de la programma-tion : ils impliquent en effet un changement de lattitude mentale du programmeur.

1.3.4 Concepts importants de lapproche objet

Dans la section1.3.2, nous avons dit que lapproche objet rapproche les donnes et leurstraitements.Maiscetteapprochenefaitpasquea,dautresconceptsimportantssontspcifiques cette approche et participent la qualit du logiciel.

Notion de classe

Tout dabord, introduisons la notion de classe. Une classe est un type de donnes abstrait

qui prcise des caractristiques (attributs et mthodes) communes toute une famille dobjetset qui permet de crer (instancier) des objets possdant ces caractristiques. Les autres conceptsimportantsquil nous faut maintenant introduire sont lencapsulation, lhritage et lagrgation.

Encapsulation

Lencapsulation consiste masquer les dtails dimplmentation dun objet, en dfinissantune interface. Linterface est la vueexterne dun objet, elle dfinit lesservices accessibles (offerts)aux utilisateurs de lobjet.

Lencapsulation facilite lvolution dune application car elle stabilise lutilisation desobjets :on peut modifier limplmentation des attributs dun objet sans modifier son interface, et donc

la faon dont lobjet est utilis.


5/24/2018 Cours-UML

22/178


Lencapsulation garantit lintgrit des donnes, car elle permet dinterdire, ou de res-treindre, laccs direct aux attributs des objets.

Hritage, Spcialisation, Gnralisation et PolymorphismeLhritage est un mcanisme de transmission des caractristiques dune classe (ses attributs

et mthodes) vers une sous-classe. Une classe peut tre spcialise en dautres classes, afin dyajouter des caractristiques spcifiques ou den adapter certaines. Plusieurs classes peuvent tregnralises en une classe qui les factorise, afin de regrouper les caractristiques communesdun ensemble de classes.

Ainsi, la spcialisation et la gnralisation permettent de construire des hirarchies declasses. Lhritage peut tre simple ou multiple. Lhritage vite la duplication et encourage larutilisation.

Le polymorphisme reprsente la facult dune mthode pouvoir sappliquer des objetsde classes diffrentes. Le polymorphisme augmente la gnricit, et donc la qualit, du code.

Agrgation

Il sagit dune relation entre deux classes, spcifiant que les objets dune classe sont descomposants de lautre classe. Une relation dagrgation permet donc de dfinir des objetscomposs dautres objets. Lagrgation permet donc dassembler des objets de base, afin deconstruire des objets plus complexes.

1.3.5 Historique la programmation par objets

Les premiers langages de programmation qui ont utilis des objets sont Simula I (1961-64) etSimula 67 (1967), conus par les informaticiens norvgiens Ole-Johan Dahl et Kristan Nygaard.Simula 67 contenait dj les objets, les classes, lhritage, lencapsulation, etc.

Alan Kay, du PARC de Xerox, avait utilis Simula dans les annes 1960. Il ralisa en 1976Smalltalk qui reste, aux yeux de certains programmeurs, le meilleur langage de programmationpar objets.

Bjarne Stroustrup a mis au point C++, une extension du langage C permettant la program-mation oriente objets, aux Bell Labs dAT&T en 1982. C++ deviendra le langage le plus utilispar les programmeurs professionnels. Il arrivera maturation en 1986, sa standardisation ANSI/ISO date de 1997.

Java est lanc par Sun en 1995. Comme il prsente plus de scurit que C++, il deviendra le

langage favori de certains programmeurs professionnels.

1.4 UML

1.4.1 Introduction

La description de la programmation par objets a fait ressortir ltendue du travail conceptuelncessaire : dfinition des classes, de leurs relations, des attributs et mthodes, des interfacesetc.

Pour programmer une application, il ne convient pas de se lancer tte baisse dans lcriture

du code : il faut dabord organiser ses ides, les documenter, puis organiser la ralisation en


5/24/2018 Cours-UML

23/178

1.4. UML

dfinissant les modules et tapes de la ralisation. Cest cette dmarche antrieure lcritureque lon appellemodlisation ; son produit est unmodle.

Les spcifications fournies par la matrise douvrage en programmation imprative taientsouvent floues : les articulations conceptuelles (structures de donnes, algorithmes de traite-

ment) sexprimant dans le vocabulaire de linformatique, le modle devait souvent tre laborpar celle-ci. Lapproche objet permet en principe la matrise douvrage de sexprimer de faonprcise selon un vocabulaire qui, tout en transcrivant les besoins du mtier, pourra tre imm-diatement compris par les informaticiens. En principe seulement, car la modlisation demandeaux matrises douvrage une comptence et un professionnalisme qui ne sont pas aujourdhuirpandus.

1.4.2 Histoire des modlisations par objets

Les mthodes utilises dans les annes 1980 pour organiser la programmation imprative

(notamment Merise) taient fondes sur la modlisation spare desdonnes et des traitements.Lorsque la programmation par objets prend de limportance au dbut des annes 1990, lancessit dune mthode qui lui soit adapte devient vidente. Plus de cinquante mthodesapparaissent entre 1990 et 1995 (Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD,OOM, OOSE, etc.) mais aucune ne parvient simposer. En 1994, le consensus se fait autour detrois mthodes :

OMT de James Rumbaugh (General Electric) fournit une reprsentation graphique desaspects statique, dynamique et fonctionnel dun systme ;

OOD de Grady Booch, dfinie pour le Department of Defense, introduit le concept depaquetage (package) ;

OOSE dIvar Jacobson (Ericsson) fonde lanalyse sur la description des besoins des utili-

sateurs (cas dutilisation, ouuse cases).Chaquemthodeavaitsesavantagesetsespartisans.Lenombredemthodesencomptition

stait rduit, mais le risque dun clatement subsistait : la profession pouvait se diviser entre cestrois mthodes, crant autant de continents intellectuels qui auraient du mal communiquer.

vnement considrable et presque miraculeux, les trois gourous qui rgnaient chacun surlune des trois mthodes se mirent daccord pour dfinir une mthode commune qui fdreraitleurs apports respectifs (on les surnomme depuis the Amigos ). UML (Unified ModelingLanguage) est n de cet effort de convergence. Ladjectifunifiedest l pour marquer quUMLunifie, et donc remplace.

En fait, et comme son nom lindique, UML na pas lambition dtre exactement une m-thode : cest un langage.

Lunification a progress par tapes. En 1995, Booch et Rumbaugh (et quelques autres) sesont mis daccord pour construire une mthode unifie, Unified Method 0.8 ; en 1996, Jacobsonles a rejoints pour produire UML 0.9 (notez le remplacement du motmthodepar le motlangage,plus modeste). Les acteurs les plus importants dans le monde du logiciel sassocient alors leffort (IBM, Microsoft, Oracle, DEC, HP, Rational, Unisys etc.) et UML 1.0 est soumis lOMG5. LOMG adopte en novembre 1997 UML 1.1 comme langage de modlisation dessystmes dinformation objets. La version dUML en cours en 2008 est UML 2.1.1 et lestravaux damlioration se poursuivent.

5 LOMG (Object Management Group) est une association amricaine but non-lucratif cre en 1989 dont lobjectifest de standardiser et promouvoir le modle objet sous toutes ses formes. LOMG est notamment la base des

spcifications UML, MOF, CORBA et IDL. LOMG est aussi lorigine de la recommandation MDA


5/24/2018 Cours-UML

24/178


UML est donc non seulement un outil intressant mais une norme qui simpose en techno-logie objets et laquelle se sont rangs tous les grands acteurs du domaine, acteurs qui ontdailleurs contribu son laboration.

1.4.3 UML en uvre

UML nest pas une mthode (i.e.une description normative des tapes de la modlisation) :ses auteurs ont en effet estim quil ntait pas opportun de dfinir une mthode en raisonde la diversit des cas particuliers. Ils ont prfr se borner dfinir un langage graphiquequi permet de reprsenter et de communiquer les divers aspects dun systme dinformation.Aux graphiques sont bien sr associs des textes qui expliquent leur contenu. UML est doncun mtalangage car il fournit les lments permettant de construire le modle qui, lui, sera lelangage du projet.

Il est impossible de donner une reprsentation graphique complte dun logiciel, ou de toutautre systme complexe, de mme quil est impossible de reprsenter entirement une statue

( trois dimensions) par des photographies ( deux dimensions). Mais il est possible de donnersur un tel systme desvuespartielles, analogues chacune une photographie dune statue, etdont la conjonction donnera une ide utilisable en pratique sans risque derreur grave.

UML 2.0 comporte ainsi treize types de diagrammes reprsentant autant de vuesdistinctespour reprsenter des concepts particuliers du systme dinformation. Ils se rpartissent en deuxgrands groupes :

Diagrammes structurels ou diagrammes statiques (UML Structure) diagramme de classes (Class diagram) diagramme dobjets (Object diagram) diagramme de composants (Component diagram) diagramme de dploiement (Deployment diagram) diagramme de paquetages (Package diagram) diagramme de structures composites (Composite structure diagram)

Diagrammes comportementaux ou diagrammes dynamiques (UML Behavior) diagramme de cas dutilisation (Use case diagram) diagramme dactivits (Activity diagram) diagramme dtats-transitions (State machine diagram) Diagrammes dinteraction (Interaction diagram)

diagramme de squence (Sequence diagram) diagramme de communication (Communication diagram) diagramme global dinteraction (Interaction overview diagram)

diagramme de temps (Timing diagram)Ces diagrammes, dune utilit variable selon les cas, ne sont pas ncessairement tous pro-duits loccasion dune modlisation. Les plus utiles pour la matrise douvrage sont les dia-grammes dactivits, de cas dutilisation, de classes, dobjets, de squence et dtats-transitions.Les diagrammes de composants, de dploiement et de communication sont surtout utiles pourla matrise duvre qui ils permettent de formaliser les contraintes de la ralisation et lasolution technique.

Diagramme de cas dutilisation

Le diagramme de cas dutilisation (cf. section2) reprsente la structure des grandes fonc-

tionnalits ncessaires aux utilisateurs du systme. Cest le premier diagramme du modle


5/24/2018 Cours-UML

25/178

1.4. UML

UML, celui o sassure la relation entre lutilisateur et les objets que le systme met en uvre.

Diagramme de classes

Le diagramme de classes (cf. section 3) est gnralement considr comme le plus importantdans un dveloppement orient objet. Il reprsente larchitecture conceptuelle du systme : ildcrit les classes que le systme utilise, ainsi que leurs liens, que ceux-ci reprsentent unembotage conceptuel (hritage) ou une relation organique (agrgation).

Diagramme dobjets

Le diagramme dobjets (cf. section3.5)permet dclairer un diagramme de classes en lillus-trant par des exemples. Il est, par exemple, utilis pour vrifier ladquation dun diagrammede classes diffrents cas possibles.

Diagramme dtats-transitions

Le diagramme dtats-transitions (cf. section5) reprsente la faon dont voluent (i.e.cyclede vie) les objets appartenant une mme classe. La modlisation du cycle de vie est essentiellepour reprsenter et mettre en forme la dynamique du systme.

Diagramme dactivits

Lediagrammedactivits(cf.section6) nest autre que la transcription dans UML de la repr-sentation du processus telle quelle a t labore lors du travail qui a prpar la modlisation :

il montre lenchanement des activits qui concourent au processus.

Diagramme de squence et de communication

Le diagramme de squence (cf. section 7.3) reprsente la succession chronologique desoprationsralisesparunacteur.Ilindiquelesobjetsquelacteurvamanipuleretlesoprationsquifontpasserdunobjetlautre.Onpeutreprsenterlesmmesoprationsparundiagrammede communication (cf. section7.2), graphe dont les nuds sont des objets et les arcs (numrotsselonlachronologie)leschangesentreobjets.Enfait,diagrammedesquenceetdiagrammedecommunication sont deux vues diffrentes mais logiquement quivalentes (on peut construirelunepartirdelautre)dunemmechronologie.Cesontdesdiagrammesdinteraction(section

7).

1.4.4 Comment prsenter un modle UML ?

La prsentation dun modle UML se compose de plusieurs documents crits en langagecourant et dun document formalis : elle ne doit pas se limiter au seul document formalis carcelui-ciestpratiquementincomprhensiblesionleprsenteseul.UnexpertenUMLseracapabledans certains cas de reconstituer les intentions initiales en lisant le modle, mais pas toujours ;et les experts en UML sont rares. Voici la liste des documents qui paraissent ncessaires :

Prsentation stratgique : elledcritpourquoilentrepriseavoulusedoterdeloutilconsidr,

les buts quelle cherche atteindre, le calendrier de ralisation prvu, etc.


5/24/2018 Cours-UML

26/178


Prsentation des processus de travail par lesquels la stratgie entend se raliser : pourpermettreau lecteur de voir comment lapplication va fonctionner en pratique, elle doit tre illustrepar une esquisse des crans qui seront affichs devant les utilisateurs de terrain.

Explication des choix qui ont guid la modlisation formelle : il sagit de synthtiser, sousles yeux du lecteur, les discussions qui ont prsid ces choix.

Modle formel : cest le document le plus pais et le plus difficile lire. Il est prfrable dele prsenter sur lIntranet de lentreprise. En effet, les diagrammes peuvent tre alorsquips de liens hypertextes permettant louverture de diagrammes plus dtaills ou decommentaires.

On doit prsenter en premier le diagramme de cas dutilisation qui montre lenchanementdes cas dutilisation au sein du processus, enchanement immdiatement comprhensible ; puisle diagramme dactivits, qui montre le contenu de chaque cas dutilisation ; puis le diagrammede squence, qui montre lenchanement chronologique des oprations lintrieur de chaquecas dutilisation. Enfin, le diagramme de classes, qui est le plus prcis conceptuellement mais

aussi le plus difficile lire car il prsente chacune des classes et leurs relations (agrgation,hritage, association, etc.).


5/24/2018 Cours-UML

27/178

1.5. TRAVAUX DIRIGS INTRODUCTION LA MODLISATION OBJET

1.5 Travaux Dirigs Introduction la modlisation objet

1.5.1 Objectifs et mise en situation

ObjectifsNous navons pas encore commenc ltude des diagrammes UML, il nest donc pas nces-

saire de respecter la notation UML au cours de ce TD.Lobjectif est de montrer que tout dveloppement est prcd dune phase danalyse et que

des mthodes diffrentes mnent des solutions diffrentes. Lobjectif doit galement permettrede distinguer lapproche structure de lapproche objet.

Mise en situation

Unebibliothquesouhaiteinformatiserlerfrencementdesesouvragesainsiquesagestiondes prts.

Les ouvrages de cette bibliothque sont des romans, caractriss par un titre, un auteuret un diteur et des bandes dessines caractrises par un titre, un dessinateur et un diteur.Concernant la gestion desouvrages, le bibliothcaire aimerait un logiciel luipermettantde saisirde nouveaux ouvrages, mettre jour des ouvrages existants, et ventuellement en supprimer.

Il voudrait pouvoir raliser peu prs les mmes oprations sur les abonns.Bien entendu, le logiciel doit permettre la gestion desprts (lemprunt et le retour).Unefonc-

tionnalit doit permettre denvoyer une lettre de rappel pour tous les exemplaires empruntsdepuis quatre jours pour les bandes dessines et deux semaines pour les romans.

Le bibliothcaire aimerait, en outre, pouvoir effectuer une recherche duvre sur le titre.Enfin, le bibliothcaire doit pouvoir effectuer une recherche dabonn sur le nom ou le prnom(sans distinction).

Attention la distinction entre une uvre et un exemplaire. Une bibliothque possdegnralement plusieurs exemplaires dune mme uvre, et ce sont toujours des exemplairesqui sont emprunts.

Remarque : Nous reviendrons rgulirement lors des travaux dirigs sur cette thmatique dela bibliothque.

1.5.2 Analyse des besoins

1. Quel est, en quelques mots, lobjectif du systme ?

2. Quels sont les utilisateurs du systme ?3. Quels sont les contextes dutilisation? En dautres termes, quelles occasions y a-t-il

interaction entre le systme et ses utilisateurs ?

4. Pourquoi doit-on distinguer les uvres et les exemplaires ?Quelles sont les implications de cette distinction sur la conception du logiciel?

1.5.3 Conception avec une approche structure (i.e.fonctionnelle)

5. Dcomposez le systme en terme de fonctions et de sous-fonctions jusqu arriver desfonctionnalits si simples quil ny a plus lieu de les dcomposer. Dessinez une structure

arborescente montrant la dcomposition du systme.


5/24/2018 Cours-UML

28/178


6. Rflchissez et donnez une solution quant la reprsentation des donnes.

7. Donnezdesdtailssurlamanirederemplirlafonctionnalitcorrespondantlarecherchedune uvre sur le titre.

1.5.4 Conception avec une approche objet

8. Identifiez les objets du systme. Regroupez les en classe. Pour chaque classe, prcisez lesattributs et mthodes qui la caractrise.

9. tablissez un schma synthtique montrant les classes du systme.Le cas chant, matrialisez les relations dhritage par une flche pointant vers la classela plus gnrale.Reliez par un trait les classes dont les objets (i.e.instances) doivent collaborer.

10. Donnezdesdtailssurlamanirederemplirlafonctionnalitcorrespondantlarecherchedune uvre sur le titre.

1.5.5 Maintenance volutive

La bibliothque souhaite maintenant voluer en mdiathque : elle veut acqurir desalbumsmusicaux sous forme de compact disques, caractriss par un titre et un interprte, et pouvanttre emprunts trois jours, ainsi que des DVD de films caractriss par un titre et un ralisateur,et pouvant tre emprunts seulement deux jours.

11. Identifiez les impacts dune telle volution sur le systme obtenu grce lapprochestructure.

12. Identifiez les impacts dune telle volution sur le systme obtenu grce lapproche objet.


5/24/2018 Cours-UML

29/178

Chapitre 2

Diagramme de cas dutilisation(Use Case Diagram)

2.1 Introduction

Bien souvent, la matrise douvrage et les utilisateurs ne sont pas des informaticiens. Il leurfaut donc un moyen simple dexprimer leurs besoins. Cest prcisment le rle des diagrammesde cas dutilisation qui permettent de recueillir, danalyser et dorganiser les besoins, et derecenser les grandes fonctionnalits dun systme. Il sagit donc de la premire tape UMLdanalyse dun systme.

Un diagramme de cas dutilisation capture le comportement dun systme, dun sous-systme, dune classe ou dun composant tel quun utilisateur extrieur le voit. Il scinde lafonctionnalit du systme en units cohrentes, les cas dutilisation, ayant un sens pour les

acteurs. Les cas dutilisation permettent dexprimer le besoin des utilisateurs dun systme, ilssont donc une vision oriente utilisateur de ce besoin au contraire dune vision informatique.

Il ne faut pas ngliger cette premire tape pour produire un logiciel conforme aux attentesdes utilisateurs. Pour laborer les cas dutilisation, il faut se fonder sur des entretiens avec lesutilisateurs.

2.2 lments des diagrammes de cas dutilisation

2.2.1 Acteur

Un acteur est lidalisation dun rle jou par une personne externe, un processus ou unechose qui interagit avec un systme.

Il se reprsente par un petit bonhomme (figure 2.1) avec son nom (i.e. son rle) inscritdessous.

Il est galement possible de reprsenter un acteur sous la forme dun classeur (cf. section2.4.3) strotyp (cf. section2.4.4) actor (figure2.2).

2.2.2 Cas dutilisation

Un cas dutilisation est une unit cohrente reprsentant une fonctionnalit visible de lex-

trieur. Il ralise un service de bout en bout, avec un dclenchement, un droulement et une fin,

29

5/24/2018 Cours-UML

30/178

CHAPITRE 2. DIAGRAMME DE CAS DUTILISATION

F. 2.1 Exemple de reprsentation dun acteur

F. 2.2 Exemple de reprsentation dun acteur sous la forme dun classeur

pour lacteur qui linitie. Un cas dutilisation modlise donc un service rendu par le systme,sans imposer le mode de ralisation de ce service.

Un cas dutilisation se reprsente par une ellipse (figure2.3)contenant le nom du cas (unverbe linfinitif), et optionnellement, au-dessus du nom, un strotype (cf. section2.4.4).

F. 2.3 Exemple de reprsentation dun cas dutilisation

Dans le cas o lon dsire prsenter les attributs ou les oprations du cas dutilisation, il estprfrable de le reprsenter sous la forme dun classeur strotyp use case (figure2.4). Nousreviendrons sur les notions dattributs ou dopration lorsque nous aborderons les diagrammesde classes et dobjets (section3).

F. 2.4 Exemple de reprsentation dun cas dutilisation sous la forme dun classeur

2.2.3 Reprsentation dun diagramme de cas dutilisation

Comme le montre la figure2.5,la frontire du systme est reprsente par un cadre. Lenom du systme figure lintrieur du cadre, en haut. Les acteurs sont lextrieur et les cas

dutilisation lintrieur.


5/24/2018 Cours-UML

31/178

2.3. RELATIONS DANS LES DIAGRAMMES DE CAS DUTILISATION

F. 2.5 Exemple simplifi de diagramme de cas dutilisation modlisant une borne daccs une banque.

2.3 Relations dans les diagrammes de cas dutilisation

2.3.1 Relations entre acteurs et cas dutilisation

Relation dassociation

F. 2.6 Diagramme de cas dutilisation reprsentant un logiciel de partage de fichiers

Une relation dassociation est chemin de communication entre un acteur et un cas dutilisa-

tion et est reprsent un trait continu (cf. figure2.5ou2.6).

Multiplicit

Lorsquunacteurpeutinteragirplusieurfoisavecuncasdutilisation,ilestpossibledajouterune multiplicit sur lassociation du ct du cas dutilisation. Le symbole * signifie plusieurs(figure2.6), exactementnscrit tout simplementn,n..msignifie entrenetm, etc. Prciser unemultiplicit sur une relation nimplique pas ncessairement que les cas sont utiliss en mmetemps.

La notion de multiplicit nest pas propre au diagramme de cas dutilisation. Nous en

reparlerons dans le chapitre consacr au diagramme de classes section3.3.4.


5/24/2018 Cours-UML

32/178

CHAPITRE 2. DIAGRAMME DE CAS DUTILISATION

Acteurs principaux et secondaires

Un acteur est qualifi deprincipalpour un cas dutilisation lorsque ce cas rend service cetacteur. Les autres acteurs sont alors qualifis de secondaires. Un cas dutilisation a au plus un

acteur principal. Un acteur principal obtient un rsultat observable du systme tandis quunacteur secondaire est sollicit pour des informations complmentaires. En gnral, lacteurprincipal initie le cas dutilisation par ses sollicitations. Le strotype primary vient ornerlassociation reliant un cas dutilisation son acteur principal, le strotype secondary estutilis pour les acteurs secondaires (figure2.6).

Cas dutilisation interne

Quand un cas nest pas directement reli un acteur, il est qualifi decas dutilisation interne.

2.3.2 Relations entre cas dutilisation

F. 2.7 Exemple de diagramme de cas dutilisation

Types et reprsentations

Il existe principalement deux types de relations :


5/24/2018 Cours-UML

33/178

2.3. RELATIONS DANS LES DIAGRAMMES DE CAS DUTILISATION

les dpendances strotypes, qui sont explicites par un strotype (les plus utiliss sontlinclusion et lextension),

et la gnralisation/spcialisation.Une dpendance se reprsente par une flche avec un trait pointill (figure2.7). Si le cas A

inclut ou tend le cas B, la flche est dirige de A vers B.Le symbole utilis pour la gnralisation est un flche avec un trait pleins dont la pointe est

un triangle ferm dsignant le cas le plus gnral (figure2.7).

Relation dinclusion

UncasAinclutuncasBsilecomportementdcritparlecasAinclutlecomportementducasB : le cas A dpend de B. Lorsque A est sollicit, B lest obligatoirement, comme une partie

Documents

Cours-UML