cours-uml

UML 2dition 2007-2008

Laurent AUDIBERT

Institut Universitaire de Technologie de Villetaneuse Dpartement Informatique Avenue Jean-Baptiste Clment 93430 Villetaneuse Adresse 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

2

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

Avant-proposLes techniques de programmation nont cess de progresser depuis lpoque de la programmation en langage binaire (cartes perfores, switch) nos jours. Cette volution a toujours t dicte 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 fait place des techniques plus volues, comme lassembleur (1947), avec larrive de lordinateur lectronique n des besoins de la guerre. Des langages plus volus ont ensuite vu le jour comme Fortran en 1956 ou Cobol en 1959. Jusque l, les techniques de programmation taient bases sur le branchement conditionnel et inconditionnel (goto) rendant les programmes importants extrmement diciles dvelopper, matriser et maintenir. La programmation structure (Pascal en 1970, C en 1972, Modula et Ada en 1979, . . .) a alors vu le jour et permis de dvelopper et de maintenir des applications toujours plus ambitieuses. Lalgorithmique ne se susant plus elle seule la n des annes 1970, le gnie logiciel est venu 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 galement rencontr 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 consquence ultime de la modularisation dicte par la matrise de la conception et de la maintenance dapplications toujours plus complexes. Cette nouvelle technique de programmation a ncessit la conception de nouvelles mthodes de modlisation. UML (Unied Modeling Language en anglais, soit langage de modlisation objet uni) est n de la fusion des trois mthodes qui simposaient dans le domaine de la modlisation objet au milieu des annes 1990 : OMT, Booch et OOSE. Dimportants acteurs industriels (IBM, Microsoft, Oracle, DEC, HP, Rational, Unisys etc.) sassocient alors leort et proposent UML 1.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. Ce document constitue le support du cours dUML 2 dispens aux tudiants du dpartement dinformatique de linstitut universitaire de technologie (IUT) de Villetaneuse en semestre dcal. Ce support a t ralis en utilisant les ouvrages cits en bibliographie. Il est en partie bas sur le livre de Charroux, Osmani et Thierry-Mieg (2005) qui constitue une bonne introduction au 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. Rumbaugh et al.. (2004) est un ouvrage de rfrence assez complet et contient un dictionnaire dtaill de la terminologie UML 2.0. Booch et al.. (2003), galement crit par les crateurs du langage UML, est un guide dapprentissage compltant bien le premier ouvrage. Muller et

3

Gaertner (2000) est un cours dUML 2.0 bien expliqu et plus complet et dtaill que Charroux et al.. (2005) mais, en contrepartie, moins accessible. Barbier (2005) constitue une approche pratique et critique dUML trs intressante. Roques (2006b) constitue une excellente approche concrte 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 auteurs les plus prolique (Roques, 2002 ; Roques & Valle, 2003 ; Roques, 2006a ; Roques, 2006b) et comptant concernant la mise en uvre dUML. Agrable lire, Volle (2006) sintresse la place de linformatique dans notre socit et plus particulirement dans lentreprise. Enn, diverses sources trouves sur Internet, inpuisable source dinformation en perptuel renouvellement, mont galement t dun grand secours. Parmi ces dernires, certaines sont incontournables, comme le cours de Piechocki (n.d.) ou encore le site Developpez.com (n.d.).

4


Table des matires1 Introduction la modlisation objet 1.1 Le gnie logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 Linformatisation . . . . . . . . . . . . . . . . . . . . . 1.1.2 Les logiciels . . . . . . . . . . . . . . . . . . . . . . . . 1.1.3 Le gnie logiciel . . . . . . . . . . . . . . . . . . . . . . 1.1.4 Notion de qualit pour un logiciel . . . . . . . . . . . 1.2 Modlisation, cycles de vie et mthodes . . . . . . . . . . . . 1.2.1 Pourquoi et comment modliser ? . . . . . . . . . . . 1.2.2 Le cycle de vie dun logiciel . . . . . . . . . . . . . . . 1.2.3 Modles de cycles de vie dun logiciel . . . . . . . . . 1.2.4 Mthodes danalyse et de conception . . . . . . . . . 1.3 De la programmation structure lapproche oriente objet . 1.3.1 Mthodes fonctionnelles ou structures . . . . . . . . 1.3.2 Lapproche oriente objet . . . . . . . . . . . . . . . . 1.3.3 Approche fonctionnelle vs. approche objet . . . . . . 1.3.4 Concepts importants de lapproche objet . . . . . . . 1.3.5 Historique la programmation par objets . . . . . . . . 1.4 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1.4.2 Histoire des modlisations par objets . . . . . . . . . 1.4.3 UML en uvre . . . . . . . . . . . . . . . . . . . . . . 1.4.4 Comment prsenter un modle UML ? . . . . . . . . . 1.5 Travaux Dirigs Introduction la modlisation objet . . . 1.5.1 Objectifs et mise en situation . . . . . . . . . . . . . . 1.5.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . 1.5.3 Conception avec une approche structure . . . . . . . 1.5.4 Conception avec une approche objet . . . . . . . . . . 1.5.5 Maintenance volutive . . . . . . . . . . . . . . . . . . Diagramme de cas dutilisation 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 lments des diagrammes de cas dutilisation . . . . . . . . 2.2.1 Acteur . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Cas dutilisation . . . . . . . . . . . . . . . . . . . . . 2.2.3 Reprsentation dun diagramme de cas dutilisation 2.3 Relations dans les diagrammes de cas dutilisation . . . . . 2.3.1 Relations entre acteurs et cas dutilisation . . . . . . 11 11 11 11 12 13 13 13 15 16 18 19 19 20 20 21 22 22 22 23 24 25 27 27 27 27 28 28 29 29 29 29 29 30 31 31

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

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

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

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

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

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

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

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

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

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

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

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

2

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

5

TABLE DES MATIRES

2.4

2.5

2.6

2.3.2 Relations entre cas dutilisation . . . . . . . . . . . . . . 2.3.3 Relations entre acteurs . . . . . . . . . . . . . . . . . . . Notions gnrales du langage UML . . . . . . . . . . . . . . . 2.4.1 Paquetage . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Espace de noms . . . . . . . . . . . . . . . . . . . . . . . 2.4.3 Classeur . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.4 Strotype . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.5 Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modlisation des besoins avec UML . . . . . . . . . . . . . . . 2.5.1 Comment identier les acteurs ? . . . . . . . . . . . . . 2.5.2 Comment recenser les cas dutilisation ? . . . . . . . . . 2.5.3 Description textuelle des cas dutilisation . . . . . . . . 2.5.4 Remarques . . . . . . . . . . . . . . . . . . . . . . . . . . Travaux Dirigs Diagramme de cas dutilisation . . . . . . . 2.6.1 Identication des acteurs et de cas dutilisation simples 2.6.2 Caisse enregistreuse . . . . . . . . . . . . . . . . . . . . 2.6.3 La bibliothque . . . . . . . . . . . . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

32 34 34 35 35 35 36 36 36 36 37 38 39 41 41 41 42 45 45 45 45 46 47 47 48 49 49 50 50 50 51 52 53 54 55 56 59 60 61 62 62 62 63 64 64 64 65

3

Diagramme de classes 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Les classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Notions de classe et dinstance de classe . . . . . . . 3.2.2 Caractristiques dune classe . . . . . . . . . . . . . 3.2.3 Reprsentation graphique . . . . . . . . . . . . . . . 3.2.4 Encapsulation, visibilit, interface . . . . . . . . . . 3.2.5 Nom dune classe . . . . . . . . . . . . . . . . . . . . 3.2.6 Les attributs . . . . . . . . . . . . . . . . . . . . . . . 3.2.7 Les mthodes . . . . . . . . . . . . . . . . . . . . . . 3.2.8 Classe active . . . . . . . . . . . . . . . . . . . . . . . 3.3 Relations entre classes . . . . . . . . . . . . . . . . . . . . . 3.3.1 Notion dassociation . . . . . . . . . . . . . . . . . . 3.3.2 Terminaison dassociation . . . . . . . . . . . . . . . 3.3.3 Association binaire et n-aire . . . . . . . . . . . . . . 3.3.4 Multiplicit ou cardinalit . . . . . . . . . . . . . . . 3.3.5 Navigabilit . . . . . . . . . . . . . . . . . . . . . . . 3.3.6 Qualication . . . . . . . . . . . . . . . . . . . . . . 3.3.7 Classe-association . . . . . . . . . . . . . . . . . . . 3.3.8 Agrgation et composition . . . . . . . . . . . . . . 3.3.9 Gnralisation et Hritage . . . . . . . . . . . . . . . 3.3.10 Dpendance . . . . . . . . . . . . . . . . . . . . . . . 3.4 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Diagramme dobjets . . . . . . . . . . . . . . . . . . . . . . 3.5.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . 3.5.2 Reprsentation . . . . . . . . . . . . . . . . . . . . . 3.5.3 Relation de dpendance dinstanciation . . . . . . . 3.6 laboration et implmentation dun diagramme de classes 3.6.1 laboration dun diagramme de classes . . . . . . . 3.6.2 Implmentation en Java . . . . . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

6


TABLE DES MATIRES

3.7

3.6.3 Implmentation en SQL . . . . . . . . . . . . . . . . Travaux Dirigs Diagramme de classe . . . . . . . . . . . 3.7.1 Proprits et relations simples . . . . . . . . . . . . 3.7.2 Identication des relations . . . . . . . . . . . . . . 3.7.3 Interfaces / hritage multiple . . . . . . . . . . . . . 3.7.4 Classes / Objets / Implmentation . . . . . . . . . . . 3.7.5 Systme de rservation de vols : Modle du domaine 3.7.6 La bibliothque . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

69 73 73 73 74 74 75 76 77 77 77 77 79 79 79 80 82 82 83 83 84 85 85 86 87 87 87 88 88 88 88 89 89 90 90 91 91 92 92 92 93 94 96 96

4

Object constraint langage (OCL) 4.1 Expression des contraintes en UML . . . . . . . . . . . . . . . . . 4.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 criture des contraintes . . . . . . . . . . . . . . . . . . . 4.1.3 Reprsentation des contraintes et contraintes prdnies 4.2 Intrt dOCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 OCL Introduction . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Illustration par lexemple . . . . . . . . . . . . . . . . . . 4.3 Typologie des contraintes OCL . . . . . . . . . . . . . . . . . . . 4.3.1 Diagramme support des exemples illustratifs . . . . . . . 4.3.2 Contexte (context) . . . . . . . . . . . . . . . . . . . . . . . 4.3.3 Invariants (inv) . . . . . . . . . . . . . . . . . . . . . . . . 4.3.4 Prconditions et postconditions (pre, post) . . . . . . . . . 4.3.5 Rsultat dune mthode (body) . . . . . . . . . . . . . . . 4.3.6 Dnition dattributs et de mthodes (def et let. . .in) . . . 4.3.7 Initialisation (init) et volution des attributs (derive) . . . 4.4 Types et oprations utilisables dans les expressions OCL . . . . 4.4.1 Types et oprateurs prdnis . . . . . . . . . . . . . . . 4.4.2 Types du modle UML . . . . . . . . . . . . . . . . . . . . 4.4.3 OCL est un langage typ . . . . . . . . . . . . . . . . . . . 4.4.4 Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Accs aux caractristiques et aux objets . . . . . . . . . . . . . . 4.5.1 Accs aux attributs et aux oprations (self ) . . . . . . . . 4.5.2 Navigation via une association . . . . . . . . . . . . . . . 4.5.3 Navigation via une association qualie . . . . . . . . . . 4.5.4 Navigation vers une classe association . . . . . . . . . . . 4.5.5 Navigation depuis une classe association . . . . . . . . . 4.5.6 Accder une caractristique rednie (oclAsType()) . . . 4.5.7 Oprations prdnies sur tous les objets . . . . . . . . . 4.5.8 Opration sur les classes . . . . . . . . . . . . . . . . . . . 4.6 Oprations sur les collections . . . . . . . . . . . . . . . . . . . . 4.6.1 Introduction : ., ->, : : et self . . . . . . . . . . . . . 4.6.2 Oprations de base sur les collections . . . . . . . . . . . 4.6.3 Opration sur les lments dune collection . . . . . . . . 4.6.4 Rgles de prcdence des oprateurs . . . . . . . . . . . . 4.7 Exemples de contraintes . . . . . . . . . . . . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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


7

TABLE DES MATIRES

5

Diagramme dtats-transitions 5.1 Introduction au formalisme . . . . . . . . . . . . . 5.1.1 Prsentation . . . . . . . . . . . . . . . . . . 5.1.2 Notion dautomate tats nis . . . . . . . 5.1.3 Diagrammes dtats-transitions . . . . . . . 5.2 tat . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Les deux acceptions du terme tat . . . . . 5.2.2 tat initial et nal . . . . . . . . . . . . . . . 5.3 vnement . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Notion dvnement . . . . . . . . . . . . . 5.3.2 vnement de type signal (signal) . . . . . 5.3.3 vnement dappel (call) . . . . . . . . . . . 5.3.4 vnement de changement (change) . . . . 5.3.5 vnement temporel (after ou when) . . . . 5.4 Transition . . . . . . . . . . . . . . . . . . . . . . . 5.4.1 Dnition et syntaxe . . . . . . . . . . . . . 5.4.2 Condition de garde . . . . . . . . . . . . . . 5.4.3 Eet dune transition . . . . . . . . . . . . . 5.4.4 Transition externe . . . . . . . . . . . . . . . 5.4.5 Transition dachvement . . . . . . . . . . . 5.4.6 Transition interne . . . . . . . . . . . . . . . 5.5 Point de choix . . . . . . . . . . . . . . . . . . . . . 5.5.1 Point de jonction . . . . . . . . . . . . . . . 5.5.2 Point de dcision . . . . . . . . . . . . . . . 5.6 tats composites . . . . . . . . . . . . . . . . . . . . 5.6.1 Prsentation . . . . . . . . . . . . . . . . . . 5.6.2 Transition . . . . . . . . . . . . . . . . . . . 5.6.3 tat historique . . . . . . . . . . . . . . . . 5.6.4 Interface : les points de connexion . . . . . 5.6.5 Concurrence . . . . . . . . . . . . . . . . . . 5.7 Travaux Dirigs Diagramme dtats-transitions 5.7.1 Porte de garage motorise enroulement . 5.7.2 Montre digitale . . . . . . . . . . . . . . . . Diagramme dactivits 6.1 Introduction au formalisme . . . . 6.1.1 Prsentation . . . . . . . . . 6.1.2 Utilisation courante . . . . 6.2 Activit et Transition . . . . . . . . 6.2.1 Action . . . . . . . . . . . . 6.2.2 Activit . . . . . . . . . . . 6.2.3 Groupe dactivits . . . . . 6.2.4 Nud dactivit . . . . . . . 6.2.5 Transition . . . . . . . . . . 6.3 Nud excutable . . . . . . . . . . 6.3.1 Nud daction . . . . . . . 6.3.2 Nud dactivit structure 6.4 Nud de contrle . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

99 99 99 99 100 100 100 101 102 102 102 102 103 103 103 103 104 104 104 104 104 105 105 107 107 107 108 108 110 110 113 113 113 117 117 117 117 118 118 119 119 119 119 121 121 122 122

6

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8


TABLE DES MATIRES

6.5

6.6 6.7 6.8

6.4.1 Nud initial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.2 Nud nal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.3 Nud de dcision et de fusion . . . . . . . . . . . . . . . . . . 6.4.4 Nud de bifurcation et dunion . . . . . . . . . . . . . . . . . Nud dobjet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5.2 Pin dentre ou de sortie . . . . . . . . . . . . . . . . . . . . . . 6.5.3 Pin de valeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5.4 Flot dobjet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5.5 Nud tampon central . . . . . . . . . . . . . . . . . . . . . . . 6.5.6 Nud de stockage des donnes . . . . . . . . . . . . . . . . . Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Travaux Dirigs Diagramme dactivits . . . . . . . . . . . . . . . . 6.8.1 Mousse au chocolat (question du contrle du 8 janvier 2007) . 6.8.2 Modlisation dune opration dinsertion dans un tableau tri 6.8.3 Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.8.4 Documentation dun cas dutilisation . . . . . . . . . . . . . .

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

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

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

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

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

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

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

123 123 123 124 125 125 125 125 125 126 126 127 127 131 131 131 131 131 135 135 135 135 136 137 138 138 139 139 139 139 140 140 144 146 147 147 147 147 148 148 151 151 151 151 152 152

7

Diagrammes dinteraction 7.1 Prsentation du formalisme . . . . . . . . . . . . . . . . . . . . 7.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7.1.2 Classeur structur . . . . . . . . . . . . . . . . . . . . . 7.1.3 Collaboration . . . . . . . . . . . . . . . . . . . . . . . . 7.1.4 Interactions et lignes de vie . . . . . . . . . . . . . . . . 7.1.5 Reprsentation gnrale . . . . . . . . . . . . . . . . . . 7.2 Diagramme de communication . . . . . . . . . . . . . . . . . . 7.2.1 Reprsentation des lignes de vie . . . . . . . . . . . . . 7.2.2 Reprsentation des connecteurs . . . . . . . . . . . . . . 7.2.3 Reprsentation des messages . . . . . . . . . . . . . . . 7.3 Diagramme de squence . . . . . . . . . . . . . . . . . . . . . . 7.3.1 Reprsentation des lignes de vie . . . . . . . . . . . . . 7.3.2 Reprsentation des messages . . . . . . . . . . . . . . . 7.3.3 Fragments dinteraction combins . . . . . . . . . . . . 7.3.4 Utilisation dinteraction . . . . . . . . . . . . . . . . . . 7.4 Travaux Dirigs Diagramme dinteraction . . . . . . . . . . . 7.4.1 Diagramme de communication : syntaxe des messages 7.4.2 Nono le petit robot . . . . . . . . . . . . . . . . . . . . . 7.4.3 Types de messages . . . . . . . . . . . . . . . . . . . . . 7.4.4 La bibliothque . . . . . . . . . . . . . . . . . . . . . . . 7.4.5 Distributeur de boisson . . . . . . . . . . . . . . . . . . Diagrammes de composants et de dploiement 8.1 Introduction . . . . . . . . . . . . . . . . . . 8.2 Diagrammes de composants . . . . . . . . . 8.2.1 Pourquoi des composants ? . . . . . 8.2.2 Notion de composant . . . . . . . . 8.2.3 Notion de port . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

8

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .


9

TABLE DES MATIRES

8.3

8.2.4 Diagramme de composants . . . . . . . Diagramme de dploiement . . . . . . . . . . . 8.3.1 Objectif du diagramme de dploiement 8.3.2 Reprsentation des nuds . . . . . . . . 8.3.3 Notion dartefact (artifact) . . . . . . . . 8.3.4 Diagramme de dploiement . . . . . . . . . . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

152 155 155 155 155 157 159 159 159 160 160 160 161 162 162 162 163 165 166 166 168 171 173

9

Mise en uvre dUML 9.1 Introduction . . . . . . . . . . . . . . . . . . . 9.1.1 UML nest pas une mthode . . . . . 9.1.2 Une mthode simple et gnrique . . 9.2 Identication des besoins . . . . . . . . . . . 9.2.1 Diagramme de cas dutilisation . . . . 9.2.2 Diagrammes de squence systme . . 9.2.3 Maquette de lIHM . . . . . . . . . . . 9.3 Phases danalyse . . . . . . . . . . . . . . . . 9.3.1 Modle du domaine . . . . . . . . . . 9.3.2 Diagramme de classes participantes . 9.3.3 Diagrammes dactivits de navigation 9.4 Phase de conception . . . . . . . . . . . . . . 9.4.1 Diagrammes dinteraction . . . . . . . 9.4.2 Diagramme de classes de conception

Bibliographie Index

10


Chapitre 1

Introduction la modlisation objet1.11.1.1

Le gnie logicielLinformatisation

Linformatisation est le phnomne le plus important de notre poque. Elle simmisce maintenant dans la pluspart des objets de la vie courante et ce, que ce soit dans lobjet proprement dit 1 , ou bien dans le processus de conception ou de fabrication de cet objet. Actuellement, linformatique est au cur de toutes les grandes entreprises. Le systme dinformation dune entreprise est compos de matriels et de logiciels. Plus prcisment, les investissements dans ce systme dinformation se rparatissent gnralement de la manire suivante : 20% pour le matriel et 80% pour le logiciel. En eet, depuis quelques annes, la fabrication du matriel est assure par quelques fabricants seulement. Ce matriel est relativement able et le march est standardis. Les problmes lis linformatique sont essentiellement des problmes de logiciel.

1.1.2

Les logiciels

Un logiciel ou une application est un ensemble de programmes, qui permet un ordinateur ou 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 petite quipe, ou un ensemble dquipes coordonnes. Le dveloppement de grands logiciels par de grandes quipes pose dimportants problmes de conception et de coordination. Or, le dveloppement 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, totalisant 8380 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 oertes,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.1

11

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), le taux 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 proviennent non de linformatique, mais de la matrise douvrage3 (i.e. le client). Pour ces raisons, le dveloppement de logiciels dans un contexte professionnel suit souvent des 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 dni (fait rare) du 7 au 11 octobre 1968, 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 able, dautre part, il tait incroyablement dicile de raliser dans des dlais prvus des logiciels satisfaisant leur cahier des charges. Lobjectif du gnie logiciel est doptimiser le cot de dveloppement du logiciel. Limportance dune approche mthodologique sest impose la suite de la crise de lindustrie du logiciel la n des annes 1970. Cette crise de lindustrie du logiciel tait principalement due : laugmentation des cots ; les dicults de maintenance et dvolution ; la non abilit ; le non respect des spcications ; le non respect des dlais. La maintenance est devenue une facette trs importante du cycle de vie dun logiciel. En eet, une enqute eectue aux USA en 1986 auprs de 55 entreprises rvle que 53% du budget total dun logiciel est aect la maintenance. Ce cot est rparti comme suit : 34% maintenance volutive (modication des spcications initiales) ; 10% maintenance adaptative (nouvel environnement, nouveaux utilisateurs) ; 17% maintenance corrective (correction des bogues) ; 16% maintenance perfective (amliorer les performance sans changer les spcications) ; 6% assistance aux utilisateurs ; 6% contrle qualit ; 7% organisation/suivi ; 4% divers. Pour apporter une rponse tous ces problmes, le gnie logiciel sintresse particulirement la manire dont le code source dun logiciel est spci puis produit. Ainsi, le gnie logiciel touche au cycle de vie des logiciels : lanalyse du besoin, llaboration des spcications, la conceptualisation, le dveloppement, la phase de test,c.f. section 1.2.1 Matrise douvrage et matrise duvre pour une dnition de ce terme. Souvent, les personnes qui doivent oprer des modications ultrieures dans le code ne sont plus les personnes qui lont dvelopp.4 3

12


1.2. MODLISATION, CYCLES DE VIE ET MTHODES

la maintenance. Les projets relatifs lingnierie logicielle sont gnralement de grande envergure et dpassent souvent les 10000 lignes de code. Cest pourquoi ces projets ncessitent une quipe de dveloppement 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 dnition de la qualit du logiciel en termes de facteurs, qui dpendent, entre autres, du domaine de lapplication et des outils utiliss. Parmi ces derniers nous pouvons citer : Validit : aptitude dun produit logiciel remplir exactement ses fonctions, dnies par le cahier des charges et les spcications. Fiabilit ou robustesse : aptitude dun produit logiciel fonctionner dans des conditions anormales. Extensibilit (maintenance) : facilit avec laquelle un logiciel se prte sa maintenance, cest-dire une modication ou une extension des fonctions qui lui sont demandes. Rutilisabilit : aptitude dun logiciel tre rutilis, en tout ou en partie, dans de nouvelles applications. Compatibilit : facilit avec laquelle un logiciel peut tre combin avec dautres logiciels. Ecacit : Utilisation optimales des ressources matrielles. Portabilit : facilit avec laquelle un logiciel peut tre transfr sous dirents environnements matriels et logiciels. Vriabilit : facilit de prparation des procdures de test. Intgrit : aptitude dun logiciel protger son code et ses donnes contre des accs non autoriss. Facilit demploi : facilit dapprentissage, dutilisation, de prparation des donnes, dinterprtation des erreurs et de rattrapage en cas derreur dutilisation. Ces facteurs sont parfois contradictoires, le choix des compromis doit seectuer en fonction du contexte.

1.21.2.1

Modlisation, cycles de vie et mthodesPourquoi et comment modliser ?

Quest-ce quun modle ? Un modle est une reprsentation abstraite et simplie (i.e. qui exclut certains dtails), dune entit (phnomne, processus, systme, etc.) du monde rel en vue de le dcrire, de lexpliquer ou de le prvoir. Modle est synonyme de thorie, mais avec une connotation pratique : un modle, cest une thorie oriente vers laction quelle doit servir. Concrtement, un modle permet de rduire la complexit dun phnomne en liminant les dtails qui ninuencent pas son comportement de manire signicative. Il rete ce que le concepteur 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 :


13


Modle mtorologique partir de donnes dobservation (satellite, . . .), il permet de prvoir les conditions climatiques pour les jours venir. Modle conomique peut par exemple permettre de simuler lvolution de cours boursiers en fonction dhypothses macro-conomiques (volution du chmage, taux de croissance, . . .). Modle dmographique dnit la composition dun panel dune population et son comportement, dans le but de abiliser des tudes statistiques, daugmenter limpact de dmarches 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 pralablement laborer de nombreux plans : plans dimplantation du btiment dans son environnement ; plans gnraux du btiment et de sa structure ; plans dtailles des dirents locaux, bureaux, appartements, . . . plans des cblages lectriques ; plans dcoulements des eaux, etc. Les trois premiers exemples sont des modles que lon qualie de prdictifs. Le dernier, plus conceptuel, possde dirents niveaux de vues comme la pluspart des modles en gnie logiciel. Pourquoi modliser ? Modliser un systme avant sa ralisation permet de mieux comprendre le fonctionnement du 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 est donc, ce titre, un vecteur privilgi pour communiquer. Cette communication est essentielle pour aboutir une comprhension commune aux direntes parties prenantes (notamment entre la matrise douvrage et la matrise duvre informatique) et prcise dun problme donn. Dans le domaine de lingnierie du logiciel, le modle permet de mieux rpartir les tches et dautomatiser certaines dentre elles. Cest galement un facteur de rduction des cots et des dlais. Par exemple, les plateformes de modlisation savent maintenant exploiter les modles pour faire de la gnration de code (au moins au niveau du squelette) voire des allerretours entre le code et le modle sans perte dinformation. Le modle est enn indispensable pour assurer un bon niveau de qualit et une maintenance ecace. En eet, une fois mise en production, 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 inuence capitale sur les solutions obtenues. Les systmes non-triviaux sont mieux modliss par un ensemble de modles indpendants. Selon les modles employs, la dmarche de modlisation nest pas la mme. Qui doit modliser ? La modlisation est souvent faite par la matrise duvre informatique (MOE). Cest malencontreux, car les priorits de la MOE rsident dans le fonctionnement de la plate-forme informatique 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

14



lorsque, aprs avoir dni 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 toujours 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 professionnalisation 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 cette professionnalisation a lieu, elle modie les rapports avec linformatique et dplace la frontire des responsabilits, ce qui contrarie parfois les informaticiens dans un premier temps, avant quils nen voient apparatre les bnces. 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 devoir de conseil vis--vis du MOA, car le SI doit tirer le meilleur parti des possibilits techniques. 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 dnie par un contrat qui prcise leurs engagements mutuels. Lorsque le produit est compliqu, il peut tre ncessaire de faire appel plusieurs fournisseurs. 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 assurant le respect des dlais xs par le MOA et en minimisant les risques. Le MOE est responsable de la qualit technique de la solution. Il doit, avant toute livraison au MOA, procder aux vrications ncessaires ( recette usine ).

1.2.2

Le cycle de vie dun logiciel

Le cycle de vie dun logiciel (en anglais software lifecycle), dsigne toutes les tapes du dveloppement dun logiciel, de sa conception sa disparition. Lobjectif dun tel dcoupage est de permettre de dnir des jalons intermdiaires permettant la validation du dveloppement logiciel, cest--dire la conformit du logiciel avec les besoins exprims, et la vrication 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 vie permet de dtecter les erreurs au plus tt et ainsi de matriser la qualit du logiciel, les dlais de sa ralisation et les cots associs. Le cycle de vie du logiciel comprend gnralement au minimum les tapes suivantes : Dnition des objectifs Cet tape consiste dnir la nalit du projet et son inscription dans une stratgie globale. Analyse des besoins et faisabilit cest--dire lexpression, le recueil et la formalisation des besoins du demandeur (le client) et de lensemble des contraintes, puis lestimation de la faisabilit de ces besoins.


15


Spcications ou conception gnrale Il sagit de llaboration des spcications de larchitecture gnrale du logiciel. Conception dtaille Cette tape consiste dnir prcisment chaque sous-ensemble du logiciel. Codage (Implmentation ou programmation) cest la traduction dans un langage de programmation des fonctionnalits dnies lors de phases de conception. Tests unitaires Ils permettent de vrier individuellement que chaque sous-ensemble du logiciel est implment conformment aux spcications. Intgration Lobjectif est de sassurer de linterfaage des dirents lments (modules) du logiciel. Elle fait lobjet de tests dintgration consigns dans un document. Qualication (ou recette) Cest--dire la vrication de la conformit du logiciel aux spcications 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 volutives (maintenance volutive) sur le logiciel. La squence et la prsence de chacune de ces activits dans le cycle de vie dpend du choix dun modle de cycle de vie entre le client et lquipe de dveloppement. Le cycle de vie permet de 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 Le modle de cycle de vie en cascade (cf. gure 1.1) a t mis au point ds 1966, puis formalis aux alentours de 1970. Dans ce modle le principe est trs simple : chaque phase se termine une date prcise par la production de certains documents ou logiciels. Les rsultats sont dnis sur la base des interactions entre tapes, ils sont soumis une revue approfondie et on ne passe la phase suivante que sils sont jugs satisfaisants. Le modle original ne comportait pas de possibilit de retour en arrire. Celle-ci a t rajoute ultrieurement sur la base quune tape ne remet en cause que ltape prcdente, ce qui, dans la pratique, savre insusant. Linconvnient majeur du modle de cycle de vie en cascade est que la vrication du bon fonctionnement du systme est ralise trop tardivement : lors de la phase dintgration, ou pire, lors de la mise en production. Modle de cycle de vie en V Le modle en V (cf. gure 1.2) demeure actuellement le cycle de vie le plus connu et certainement le plus utilis. Il sagit dun modle en cascade dans lequel le dveloppement des tests et du logiciels sont eectus de manire synchrone. Le principe de ce modle est quavec toute dcomposition doit tre dcrite la recomposition et que toute description dun composant est accompagne de tests qui permettront de sassurer quil correspond sa description.

16



F. 1.1 Modle du cycle de vie en cascade

F. 1.2 Modle du cycle de vie en V


17


Ceci rend explicite la prparation des dernires phases (validation-vrication) par les premires (construction du logiciel), et permet ainsi dviter un cueil bien connu de la spcication du logiciel : noncer une proprit quil est impossible de vrier objectivement aprs la ralisation. Cependant, ce modle soure toujours du problme de la vrication trop tardive du bon fonctionnement du systme. Modle de cycle de vie en spirale Propos par B. Boehm en 1988, ce modle est beaucoup plus gnral que le prcdent. Il met laccent sur lactivit danalyse des risques : chaque cycle de la spirale se droule en quatre phases : 1. dtermination, partir des rsultats des cycles prcdents, ou de lanalyse prliminaire des 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 vrication de la solution retenue, un modle classique (cascade ou en V) peut tre utilis ici ; 4. revue des rsultats et vrication du cycle suivant. Lanalyse prliminaire est ane au cours des premiers cycles. Le modle utilise des maquettes exploratoires pour guider la phase de conception du cycle suivant. Le dernier cycle se termine par un processus de dveloppement classique. Modle par incrment Dans les modles prcdents un logiciel est dcompos en composants dvelopps sparment et intgrs la n 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. Chaque incrment 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 ; il permet un meilleur lissage du temps et de leort de dveloppement grce la possibilit de recouvrement (paralllisation) des direntes 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 spcis globalement, 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 notations standards qui aident concevoir des logiciels de qualit. Il existe direntes manires pour classer ces mthodes, dont :

18


1.3. DE LA PROGRAMMATION STRUCTURE LAPPROCHE ORIENTE OBJET

La distinction entre composition et dcomposition : Elle met en opposition dune part les mthodes ascendantes qui consistent construire un logiciel par composition partir de modules existants et, dautre part, les mthodes descendantes qui dcomposent rcursivement le systme jusqu arriver des modules programmables simplement. La distinction entre fonctionnel (dirige par le traitement) et oriente objet : Dans la stratgie fonctionnelle (galement qualie de structure) un systme est vu comme un ensemble hirarchique dunits en interaction, ayant chacune une fonction clairement dnie. Les fonctions disposent dun tat local, mais le systme a un tat partag, qui est centralis et accessible par lensemble des fonctions. Les stratgies orientes objet considrent quun systme est un ensemble dobjets interagissants. Chaque objet dispose dun ensemble dattributs dcrivant son tat et ltat du systme est dcrit (de faon dcentralise) par ltat de lensemble.

1.31.3.1

De la programmation structure lapproche oriente objetMthodes fonctionnelles ou structures

F. 1.3 Reprsentation graphique dune approche fonctionnelle

Les mthodes fonctionnelles (galement qualies de mthodes structures) trouvent leur origine dans les langages procduraux. Elles mettent en vidence les fonctions assurer et proposent une approche hirarchique descendante et modulaire. Ces mthodes utilisent intensivement les ranements successifs pour produire des spcications dont lessentielle est sous forme de notation graphique en diagrammes de ots de donnes. Le plus haut niveau reprsente lensemble du problme (sous forme dactivit, de donnes ou de processus, selon la mthode). Chaque niveau est ensuite dcompos en respectant les entres/sorties du niveau suprieur. La dcomposition se poursuit jusqu arriver des composants matrisables (cf. gure 1.3). Lapproche fonctionnelle dissocie le problme de la reprsentation des donnes, du problme du traitement de ces donnes. Sur la gure 1.3, les donnes du problme sont reprsentes sur la gauche. Des ches transversalles matrialisent la manipulation de ces donnes par des sousfonctions. Cet accs peut-tre direct (cest parfois le cas quand les donnes sont regroupes dans une base de donnes), ou peut tre ralis par le passage de paramtre depuis le programme principal. 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


19


tches du projet et leurs interactions, mais aussi de dcrire le systme que le projet vise tudier, crer ou modier, en mettant notamment en vidence les parties qui constituent le systme, la nalit 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 nalit 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, identis et possdant des caractristiques. Une caractristique est soit un attribut (i.e. une donne caractrisant ltat de lobjet), soit une entit comportementale de lobjet (i.e. une fonction). La fonctionnalit du logiciel merge alors de linteraction entre les dirents objets qui le constituent. 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, indpendamment de son tat. On construit gnralement cette identit grce un identiant dcoulant naturellement du problme (par exemple un produit pourra tre repr par un code, une voiture par un numro de srie, etc.) Les attributs Il sagit des donnes caractrisant lobjet. Ce sont des variables stockant des informations sur ltat de lobjet. Les mthodes Les mthodes dun objet caractrisent son comportement, cest--dire lensemble des actions (appeles oprations) que lobjet est mme de raliser. Ces oprations permettent de faire ragir lobjet aux sollicitations extrieures (ou dagir sur les autres objets). De plus, les oprations sont troitement lies aux attributs, car leurs actions peuvent dpendre des valeurs des attributs, ou bien les modier. La dicult de cette modlisation consiste crer une reprsentation abstraite, sous forme dobjets, 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 logicielles 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 objet

Selon 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 langage pourrait galement tre crit dans nimporte quel autre langage. Ainsi, tout ce que lon fait avec un langage de programmation par objets pourrait tre fait en programmation imprative. La dirence entre une approche fonctionnelle et une approche objet nest donc pas dordre logique, mais pratique. Lapproche structure privilgie la fonction comme moyen dorganisation du logiciel. Ce nest pas pour cette raison que lapproche objet est une approche non fonctionnelle. En eet, les mthodes dun objet sont des fonctions. Ce qui direncie sur le fond lapproche objet de lapproche fonctionnelle, cest que les fonctions obtenues lissue de la mise en uvre de lune

20


1.3. DE LA PROGRAMMATION STRUCTURE LAPPROCHE ORIENTE OBJET

ou lautre mthode sont distinctes. Lapproche objet est une approche oriente donne. Dans cette approche, les fonctions se dduisent dun regroupement de champs de donnes formant une entit cohrente, logique, tangible et surtout stable quant au problme trait. Lapproche structure classique privilgie une organisation des donnes postrieure la dcouverte des grandes, puis petites fonctions qui les dcomposent, lensemble constituant les services qui rpondent aux besoins. En approche objet, lvolution des besoins aura le plus souvent tendance se prsenter comme un changement de linteraction des objets. Sil faut apporter une modication aux donnes, seul lobjet incrimin (encapsulant cette donne) sera modi. Toutes les fonctions modier sont bien identies : elles se trouvent dans ce mme objet : ce sont ses mthodes. Dans une approche structure, lvolution des besoins entrane souvent une dgnrescence, ou une profonde remise en question, de la topologie typique de la gure 1.3 car la dcomposition des units de traitement (du programme principal aux sous-fonctions) est directement dicte par ces besoins. Dautre part, une modication des donnes entrane gnralement une modication dun nombre important de fonctions parpilles et diciles identier dans la hirarchie de cette dcomposition. En fait, la modularit nest pas antinomique de lapproche structure. Les modules rsultant de la dcomposition objet sont tout simplement dirents de ceux manant de lapproche structure. Les units de traitement, et surtout leur dpendance dans la topologie de la gure 1.3 sont initialement bons. Cest leur rsistance au temps, contrairement aux modules objet, qui est source de problme. La structure dun logiciel issue dune approche structure est beaucoup moins mallable, adaptable, que celle issue dune approche objet. Ainsi la technologie objet est la consquence ultime de la modularisation du logiciel, dmarche qui vise matriser sa production et son volution. Mais malgr cette continuit logique les langages objet ont apport en pratique un profond changement dans lart de la programmation : ils impliquent en eet un changement de lattitude mentale du programmeur.

1.3.4

Concepts importants de lapproche objet

Dans la section 1.3.2, nous avons dit que lapproche objet rapproche les donnes et leurs traitements. Mais cette approche ne fait pas que a, dautres concepts importants sont spciques 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 dobjets et qui permet de crer (instancier) des objets possdant ces caractristiques. Les autres concepts importants quil nous faut maintenant introduire sont lencapsulation, lhritage et lagrgation. Encapsulation Lencapsulation consiste masquer les dtails dimplmentation dun objet, en dnissant une interface. Linterface est la vue externe dun objet, elle dnit les services accessibles (oerts) aux utilisateurs de lobjet. Lencapsulation facilite lvolution dune application car elle stabilise lutilisation des objets : on peut modier limplmentation des attributs dun objet sans modier son interface, et donc la faon dont lobjet est utilis.


21


Lencapsulation garantit lintgrit des donnes, car elle permet dinterdire, ou de restreindre, laccs direct aux attributs des objets. Hritage, Spcialisation, Gnralisation et Polymorphisme Lhritage 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, an dy ajouter des caractristiques spciques ou den adapter certaines. Plusieurs classes peuvent tre gnralises en une classe qui les factorise, an de regrouper les caractristiques communes dun ensemble de classes. Ainsi, la spcialisation et la gnralisation permettent de construire des hirarchies de classes. Lhritage peut tre simple ou multiple. Lhritage vite la duplication et encourage la rutilisation. Le polymorphisme reprsente la facult dune mthode pouvoir sappliquer des objets de classes direntes. Le polymorphisme augmente la gnricit, et donc la qualit, du code. Agrgation Il sagit dune relation entre deux classes, spciant que les objets dune classe sont des composants de lautre classe. Une relation dagrgation permet donc de dnir des objets composs dautres objets. Lagrgation permet donc dassembler des objets de base, an de construire 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) et Simula 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 1976 Smalltalk qui reste, aux yeux de certains programmeurs, le meilleur langage de programmation par objets. Bjarne Stroustrup a mis au point C++, une extension du langage C permettant la programmation oriente objets, aux Bell Labs dAT&T en 1982. C++ deviendra le langage le plus utilis par 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.41.4.1

UMLIntroduction

La description de la programmation par objets a fait ressortir ltendue du travail conceptuel ncessaire : dnition des classes, de leurs relations, des attributs et mthodes, des interfaces etc. 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

22


1.4. UML

dnissant les modules et tapes de la ralisation. Cest cette dmarche antrieure lcriture que lon appelle modlisation ; son produit est un modle. Les spcications fournies par la matrise douvrage en programmation imprative taient souvent oues : les articulations conceptuelles (structures de donnes, algorithmes de traitement) sexprimant dans le vocabulaire de linformatique, le modle devait souvent tre labor par celle-ci. Lapproche objet permet en principe la matrise douvrage de sexprimer de faon prcise selon un vocabulaire qui, tout en transcrivant les besoins du mtier, pourra tre immdiatement compris par les informaticiens. En principe seulement, car la modlisation demande aux matrises douvrage une comptence et un professionnalisme qui ne sont pas aujourdhui rpandus.

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 des donnes et des traitements. Lorsque la programmation par objets prend de limportance au dbut des annes 1990, la ncessit dune mthode qui lui soit adapte devient vidente. Plus de cinquante mthodes apparaissent 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 de trois mthodes : OMT de James Rumbaugh (General Electric) fournit une reprsentation graphique des aspects statique, dynamique et fonctionnel dun systme ; OOD de Grady Booch, dnie pour le Department of Defense, introduit le concept de paquetage (package) ; OOSE dIvar Jacobson (Ericsson) fonde lanalyse sur la description des besoins des utilisateurs (cas dutilisation, ou use cases). Chaque mthode avait ses avantages et ses partisans. Le nombre de mthodes en comptition stait rduit, mais le risque dun clatement subsistait : la profession pouvait se diviser entre ces trois mthodes, crant autant de continents intellectuels qui auraient du mal communiquer. vnement considrable et presque miraculeux, les trois gourous qui rgnaient chacun sur lune des trois mthodes se mirent daccord pour dnir une mthode commune qui fdrerait leurs apports respectifs (on les surnomme depuis the Amigos ). UML (Unied Modeling Language) est n de cet eort de convergence. Ladjectif unied est l pour marquer quUML unie, et donc remplace. En fait, et comme son nom lindique, UML na pas lambition dtre exactement une mthode : cest un langage. Lunication a progress par tapes. En 1995, Booch et Rumbaugh (et quelques autres) se sont mis daccord pour construire une mthode unie, Unied Method 0.8 ; en 1996, Jacobson les a rejoints pour produire UML 0.9 (notez le remplacement du mot mthode par le mot langage, plus modeste). Les acteurs les plus importants dans le monde du logiciel sassocient alors leort (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 des systmes dinformation objets. La version dUML en cours en 2008 est UML 2.1.1 et les travaux damlioration se poursuivent.LOMG (Object Management Group) est une association amricaine but non-lucratif cre en 1989 dont lobjectif est de standardiser et promouvoir le modle objet sous toutes ses formes. LOMG est notamment la base des spcications UML, MOF, CORBA et IDL. LOMG est aussi lorigine de la recommandation MDA5


23


UML est donc non seulement un outil intressant mais une norme qui simpose en technologie objets et laquelle se sont rangs tous les grands acteurs du domaine, acteurs qui ont dailleurs 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 eet estim quil ntait pas opportun de dnir une mthode en raison de la diversit des cas particuliers. Ils ont prfr se borner dnir un langage graphique qui 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 donc un mtalangage car il fournit les lments permettant de construire le modle qui, lui, sera le langage du projet. Il est impossible de donner une reprsentation graphique complte dun logiciel, ou de tout autre systme complexe, de mme quil est impossible de reprsenter entirement une statue ( trois dimensions) par des photographies ( deux dimensions). Mais il est possible de donner sur un tel systme des vues partielles, analogues chacune une photographie dune statue, et dont la conjonction donnera une ide utilisable en pratique sans risque derreur grave. UML 2.0 comporte ainsi treize types de diagrammes reprsentant autant de vues distinctes pour reprsenter des concepts particuliers du systme dinformation. Ils se rpartissent en deux grands 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 produits loccasion dune modlisation. Les plus utiles pour la matrise douvrage sont les diagrammes dactivits, de cas dutilisation, de classes, dobjets, de squence et dtats-transitions. Les diagrammes de composants, de dploiement et de communication sont surtout utiles pour la matrise duvre qui ils permettent de formaliser les contraintes de la ralisation et la solution technique. Diagramme de cas dutilisation Le diagramme de cas dutilisation (cf. section 2) reprsente la structure des grandes fonctionnalits ncessaires aux utilisateurs du systme. Cest le premier diagramme du modle

24


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 important dans un dveloppement orient objet. Il reprsente larchitecture conceptuelle du systme : il dcrit les classes que le systme utilise, ainsi que leurs liens, que ceux-ci reprsentent un embotage conceptuel (hritage) ou une relation organique (agrgation). Diagramme dobjets Le diagramme dobjets (cf. section 3.5) permet dclairer un diagramme de classes en lillustrant par des exemples. Il est, par exemple, utilis pour vrier ladquation dun diagramme de classes dirents cas possibles. Diagramme dtats-transitions Le diagramme dtats-transitions (cf. section 5) reprsente la faon dont voluent (i.e. cycle de vie) les objets appartenant une mme classe. La modlisation du cycle de vie est essentielle pour reprsenter et mettre en forme la dynamique du systme. Diagramme dactivits Le diagramme dactivits (cf. section 6) nest autre que la transcription dans UML de la reprsentation 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 des oprations ralises par un acteur. Il indique les objets que lacteur va manipuler et les oprations qui font passer dun objet lautre. On peut reprsenter les mmes oprations par un diagramme de communication (cf. section 7.2), graphe dont les nuds sont des objets et les arcs (numrots selon la chronologie) les changes entre objets. En fait, diagramme de squence et diagramme de communication sont deux vues direntes mais logiquement quivalentes (on peut construire lune partir de lautre) dune mme chronologie. Ce sont des diagrammes dinteraction (section 7).

1.4.4

Comment prsenter un modle UML ?

La prsentation dun modle UML se compose de plusieurs documents crits en langage courant et dun document formalis : elle ne doit pas se limiter au seul document formalis car celui-ci est pratiquement incomprhensible si on le prsente seul. Un expert en UML sera capable dans 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 : elle dcrit pourquoi lentreprise a voulu se doter de loutil considr, les buts quelle cherche atteindre, le calendrier de ralisation prvu, etc.


25


Prsentation des processus de travail par lesquels la stratgie entend se raliser : pour permettre au lecteur de voir comment lapplication va fonctionner en pratique, elle doit tre illustre par une esquisse des crans qui seront achs devant les utilisateurs de terrain. Explication des choix qui ont guid la modlisation formelle : il sagit de synthtiser, sous les yeux du lecteur, les discussions qui ont prsid ces choix. Modle formel : cest le document le plus pais et le plus dicile lire. Il est prfrable de le prsenter sur lIntranet de lentreprise. En eet, les diagrammes peuvent tre alors quips de liens hypertextes permettant louverture de diagrammes plus dtaills ou de commentaires. On doit prsenter en premier le diagramme de cas dutilisation qui montre lenchanement des cas dutilisation au sein du processus, enchanement immdiatement comprhensible ; puis le diagramme dactivits, qui montre le contenu de chaque cas dutilisation ; puis le diagramme de squence, qui montre lenchanement chronologique des oprations lintrieur de chaque cas dutilisation. Enn, le diagramme de classes, qui est le plus prcis conceptuellement mais aussi le plus dicile lire car il prsente chacune des classes et leurs relations (agrgation, hritage, association, etc.).

26


1.5. TRAVAUX DIRIGS INTRODUCTION LA MODLISATION OBJET

1.51.5.1

Travaux Dirigs Introduction la modlisation objetObjectifs et mise en situation

Objectifs Nous navons pas encore commenc ltude des diagrammes UML, il nest donc pas ncessaire 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 direntes mnent des solutions direntes. Lobjectif doit galement permettre de distinguer lapproche structure de lapproche objet. Mise en situation Une bibliothque souhaite informatiser le rfrencement de ses ouvrages ainsi que sa gestion des prts. Les ouvrages de cette bibliothque sont des romans, caractriss par un titre, un auteur et un diteur et des bandes dessines caractrises par un titre, un dessinateur et un diteur. Concernant la gestion des ouvrages, le bibliothcaire aimerait un logiciel lui permettant de saisir de 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 des prts (lemprunt et le retour). Une fonctionnalit doit permettre denvoyer une lettre de rappel pour tous les exemplaires emprunts depuis quatre jours pour les bandes dessines et deux semaines pour les romans. Le bibliothcaire aimerait, en outre, pouvoir eectuer une recherche duvre sur le titre. Enn, le bibliothcaire doit pouvoir eectuer une recherche dabonn sur le nom ou le prnom (sans distinction). Attention la distinction entre une uvre et un exemplaire. Une bibliothque possde gnralement plusieurs exemplaires dune mme uvre, et ce sont toujours des exemplaires qui sont emprunts. Remarque : Nous reviendrons rgulirement lors des travaux dirigs sur cette thmatique de la 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 des fonctionnalits si simples quil ny a plus lieu de les dcomposer. Dessinez une structure arborescente montrant la dcomposition du systme.


27


6. Rchissez et donnez une solution quant la reprsentation des donnes. 7. Donnez des dtails sur la manire de remplir la fonctionnalit correspondant la recherche dune uvre sur le titre.

1.5.4

Conception avec une approche objet

8. Identiez les objets du systme. Regroupez les en classe. Pour chaque classe, prcisez les attributs et mthodes qui la caractrise. 9. tablissez un schma synthtique montrant les classes du systme. Le cas chant, matrialisez les relations dhritage par une che pointant vers la classe la plus gnrale. Reliez par un trait les classes dont les objets (i.e. instances) doivent collaborer. 10. Donnez des dtails sur la manire de remplir la fonctionnalit correspondant la recherche dune uvre sur le titre.

1.5.5

Maintenance volutive

La bibliothque souhaite maintenant voluer en mdiathque : elle veut acqurir des albums musicaux sous forme de compact disques, caractriss par un titre et un interprte, et pouvant tre emprunts trois jours, ainsi que des DVD de lms caractriss par un titre et un ralisateur, et pouvant tre emprunts seulement deux jours. 11. Identiez les impacts dune telle volution sur le systme obtenu grce lapproche structure. 12. Identiez les impacts dune telle volution sur le systme obtenu grce lapproche objet.

28


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 leur faut donc un moyen simple dexprimer leurs besoins. Cest prcisment le rle des diagrammes de cas dutilisation qui permettent de recueillir, danalyser et dorganiser les besoins, et de recenser les grandes fonctionnalits dun systme. Il sagit donc de la premire tape UML danalyse dun systme. Un diagramme de cas dutilisation capture le comportement dun systme, dun soussystme, dune classe ou dun composant tel quun utilisateur extrieur le voit. Il scinde la fonctionnalit 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, ils sont 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 attentes des utilisateurs. Pour laborer les cas dutilisation, il faut se fonder sur des entretiens avec les utilisateurs.

2.22.2.1

lments des diagrammes de cas dutilisationActeur

Un acteur est lidalisation dun rle jou par une personne externe, un processus ou une chose qui interagit avec un systme. Il se reprsente par un petit bonhomme (gure 2.1) avec son nom (i.e. son rle) inscrit dessous. Il est galement possible de reprsenter un acteur sous la forme dun classeur (cf. section 2.4.3) strotyp (cf. section 2.4.4) actor (gure 2.2).

2.2.2

Cas dutilisation

Un cas dutilisation est une unit cohrente reprsentant une fonctionnalit visible de lextrieur. Il ralise un service de bout en bout, avec un dclenchement, un droulement et une n,

29

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 (gure 2.3) contenant le nom du cas (un verbe linnitif), et optionnellement, au-dessus du nom, un strotype (cf. section 2.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 est prfrable de le reprsenter sous la forme dun classeur strotyp use case (gure 2.4). Nous reviendrons sur les notions dattributs ou dopration lorsque nous aborderons les diagrammes de classes et dobjets (section 3).

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 gure 2.5, la frontire du systme est reprsente par un cadre. Le nom du systme gure lintrieur du cadre, en haut. Les acteurs sont lextrieur et les cas dutilisation lintrieur.

30


2.3. RELATIONS DANS LES DIAGRAMMES DE CAS DUTILISATION

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

2.32.3.1

Relations dans les diagrammes de cas dutilisationRelations entre acteurs et cas dutilisation

Relation dassociation

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

Une relation dassociation est chemin de communication entre un acteur et un cas dutilisation et est reprsent un trait continu (cf. gure 2.5 ou 2.6).

Multiplicit Lorsquun acteur peut interagir plusieur fois avec un cas dutilisation, il est possible dajouter une multiplicit sur lassociation du ct du cas dutilisation. Le symbole * signie plusieurs (gure 2.6), exactement n scrit tout simplement n, n..m signie entre n et m, etc. Prciser une multiplicit sur une relation nimplique pas ncessairement que les cas sont utiliss en mme temps. La notion de multiplicit nest pas propre au diagramme de cas dutilisation. Nous en reparlerons dans le chapitre consacr au diagramme de classes section 3.3.4.


31


Acteurs principaux et secondaires Un acteur est quali de principal pour un cas dutilisation lorsque ce cas rend service cet acteur. Les autres acteurs sont alors qualis de secondaires. Un cas dutilisation a au plus un acteur principal. Un acteur principal obtient un rsultat observable du systme tandis quun acteur secondaire est sollicit pour des informations complmentaires. En gnral, lacteur principal initie le cas dutilisation par ses sollicitations. Le strotype primary vient orner lassociation reliant un cas dutilisation son acteur principal, le strotype secondary est utilis pour les acteurs secondaires (gure 2.6). Cas dutilisation interne Quand un cas nest pas directement reli un acteur, il est quali de cas 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 :

32


2.3. RELATIONS DANS LES DIAGRAMMES DE CAS DUTILISATION

les dpendances strotypes, qui sont explicites par un strotype (les plus utiliss sont linclusion et lextension), et la gnralisation/spcialisation. Une dpendance se reprsente par une che avec un trait pointill (gure 2.7). Si le cas A inclut ou tend le cas B, la che est dirige de A vers B. Le symbole utilis pour la gnralisation est un che avec un trait pleins dont la pointe est un triangle ferm dsignant le cas le plus gnral (gure 2.7). Relation dinclusion Un cas A inclut un cas B si le comportement dcrit par le cas A inclut le comportement du cas B : le cas A dpend de B. Lorsque A est sollicit, B lest obligatoirement, comme une partie de A. Cette dpendance est symbolise par le strotype include (gure 2.7). Par exemple, laccs aux informations dun compte bancaire inclut ncessairement une phase dauthentication avec un identiant et un mot de passe (gure 2.7). Les inclusions permettent essentiellement de factoriser une partie de la description dun cas dutilisation qui serait commune dautres cas dutilisation (cf. le cas Sauthentier de la gure 2.7). Les inclusions permettent galement de dcomposer un cas complexe en sous-cas plus simples (gure 2.8). Cependant, il ne faut surtout pas abuser de ce type de dcomposition : il faut viter de raliser du dcoupage fonctionnel dun cas dutilisation en plusieurs sous-cas dutilisation pour ne pas retomber dans le travers de la dcomposition fonctionnelle. Attention galement au fait que, les cas dutilisation ne senchanent pas, puisquil ny a aucune reprsentation temporelle dans un diagramme de cas dutilisation.

F. 2.8 Relations entre cas pour dcomposer un cas complexe

Relation dextension La relation dextension est probablement la plus utile car elle a une smantique qui a un sens du point de vue mtier au contraire des deux autres qui sont plus des artices dinformaticiens. On dit quun cas dutilisation A tend un cas dutilisation B lorsque le cas dutilisation A peut tre appel au cours de lexcution du cas dutilisation B. Excuter B peut ventuellement entraner lexcution de A : contrairement linclusion, lextension est optionnelle. Cette dpendance est symbolise par le strotype extend (gure 2.7).


33


Lextension peut intervenir un point prcis du cas tendu. Ce point sappelle le point dextension. Il porte un nom, qui gure dans un compartiment du cas tendu sous la rubrique point dextension, et est ventuellement associ une contrainte indiquant le moment o lextension intervient. Une extension est souvent soumise condition. Graphiquement, la condition est exprime sous la forme dune note. La gure 2.7 prsente lexemple dune banque o la vrication du solde du compte nintervient que si la demande de retrait dpasse 20 euros. Relation de gnralisation Un cas A est une gnralisation dun cas B si B est un cas particulier de A. Dans la gure 2.7, la consultation dun compte via Internet est un cas particulier de la consultation. Cette relation de gnralisation/spcialisation est prsente dans la plupart des diagrammes UML et se traduit par le concept dhritage dans les langages orients objet.

2.3.3

Relations entre acteurs

La seule relation possible entre deux acteurs est la gnralisation : un acteur A est une gnralisation dun acteur B si lacteur A peut tre substitu par lacteur B. Dans ce cas, tous les cas dutilisation accessibles A le sont aussi B, mais linverse nest pas vrai. Le symbole utilis pour la gnralisation entre acteurs est une che avec un trait plein dont la pointe est un triangle ferm dsignant lacteur le plus gnral (comme nous lavons dj vu pour la relation de gnralisation entre cas dutilisation). Par exemple, la gure 2.9 montre que le directeur des ventes est un prpos aux commandes avec un pouvoir supplmentaire : en plus de pouvoir passer et suivre une commande, il peut grer le stock. Par contre, le prpos aux commandes ne peut pas grer le stock.

F. 2.9 Relations entre acteurs

2.4

Notions gnrales du langage UML

Les lments du langage UML que nous abordons ici ne sont pas spciques au diagramme de cas dutilisation mais sont gnraux. Nous avons dj utilis certains de ces lments dans

34


2.4. NOTIONS GNRALES DU LANGAGE UML

ce chapitre et nous utiliserons les autres dans les chapitres qui suivent, notamment dans le chapitre sur les diagrammes de classes (section 3).

2.4.1

Paquetage

F. 2.10 Reprsentations dun paquetage Un paquetage est un regroupement dlments de modle et de diagrammes. Il permet ainsi dorganiser des lments de modlisation en groupes. Il peut contenir tout type dlment de modle : des classes, des cas dutilisation, des interfaces, des diagrammes, . . . et mme des paquetages imbriqus (dcomposition hirarchique). Un paquetage se reprsente comme un dossier avec son nom inscrit dedans (gure 2.10, diagramme de gauche). Il est possible de reprsenter explicitement le contenu dun paquetage. Dans ce cas, le nom du paquetage est plac dans longlet (gure 2.10, diagramme de droite). Les lments contenus dans un paquetage doivent reprsenter un ensemble fortement cohrent et sont gnralement de mme nature et de mme niveau smantique. Tout lment nappartient qu un seul paquetage. Les paquetage constituent un mcanisme de gestion important des problmes de grande taille. Ils permettent dviter les grands modles plats et de cloisonner des lments constitutifs dun systme voluant des rythmes dirents ou dvelopps par des quipes direntes. Il existe un paquetage racine unique, ventuellement anonyme, qui contient la totalit des modles dun systme.

2.4.2

Espace de noms

Les espaces de noms sont des paquetages, des classeurs, etc. On peut dterminer un lment nomm de faon unique par son nom quali, qui est constitu de la srie des noms des paquetages ou des autres espaces de noms depuis la racine jusqu llment en question. Dans un nom quali, chaque espace de nom est spar par deux doubles points (::). Par exemple, si un paquetage B est inclus dans un paquetage A et contient une classe X, il faut crire A::B::X pour pouvoir utiliser la classe X en dehors du contexte du paquetage B.

2.4.3

Classeur

Les paquetages et les relations de gnralisation ne peuvent avoir dinstance. Dune manire gnrale, les lments de modlisation pouvant en avoir sont reprsents dans des classeurs1 . Plus important encore, un classeur est un lment de modle qui dcrit une unit structurelle ou comportementale. Un classeur modlise un concept discret qui dcrit un lment (i.e. objet) dot dune identit (i.e. un nom), dune structure ou dun tat (i.e. des attributs), dun comportement (i.e. desCertains lments, comme les associations, peuvent avoir des instances bien quils ne soient pas reprsents dans des classeurs.1


35


oprations), de relations et dune structure interne facultative. Il peut participer des relations dassociation, de gnralisation, de dpendance et de contrainte. On le dclare dans un espace de noms, comme un paquetage ou une autre classe. Un classeur se reprsente par un rectangle, en traits pleins, contenant ventuellement des compartiments. Les acteurs et les cas dutilisation sont des classeurs. Tout au long de ce cours, nous retrouverons le terme de classeur car cette notion englobe aussi les classes, les interfaces, les signaux, les nuds, les composants, les sous-systmes, etc. Le type de classeur le plus important tant, bien videmment, la classe (cf. section 3).

2.4.4

Strotype

Un strotype est une annotation sappliquant sur un lment de modle. Il na pas de dnition formelle, mais permet de mieux caractriser des varits dun mme concept. Il permet donc dadapter le langage des situations particulires. Il est reprsent par une chanes de caractres entre guillemets ( ) dans, ou proximit du symbole de llment de modle de base. Par exemple, la gure 2.4 reprsente un cas dutilisation par un rectangle. UML utilise aussi les rectangles pour reprsenter les classes (cf. section 3). La notation nest cependant pas ambigu grce la prsence du strotype use case .

2.4.5

Note

F. 2.11 Exemple dutilisation dune note pour prciser que le solde dun compte doit toujours tre positif.

Une note contient une information textuelle comme un commentaire, un corps de mthode ou une contrainte. Graphiquement, elle est reprsente par un rectangle dont langle suprieur droit est pli. Le texte contenu dans le rectangle nest pas contraint par UML. Une note nindique pas explicitement le type dlment quelle contient, toute lintelligibilit dune note doit tre contenu dans le texte mme. On peut relier une note llment quelle dcrit grce une ligne en pointills.

cours-uml

Documents

et mthodes

conception et

dvelopper et

et muller et gaertner

concevoir et

modula et ada en

version duml en cours

smalltalk en