PAGE D'ACCUEIL DU COURS La version finalise, largement enrichie et corrige de cette premire bauche de cours est parue, dans la collection Info+ chez les ditions Ellipses, sous le titre UML 2 - de l'apprentissage la pratique (cours et exercices) (FNAC, amazon.fr)

UML 2Laurent AUDIBERT

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 difficiles 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 suffisant plus elle seule la fin des annes 1970, le gnie logiciel est venu placer la mthodologie au c ur 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 (Unified Modeling Language en anglais, soit langage de modlisation objet unifi) 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 leffort 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 [7] qui constitue une bonne introduction au langage UML. Aomar Osmani est lorigine du cours dUML dans notre IUT.1

[27], [5], [3] [26] et [16] ont galement t largement utiliss. [27] est un ouvrage de rfrence assez complet et contient un dictionnaire dtaill de la terminologie UML 2.0. [5], galement crit par les crateurs du langage UML, est un guide dapprentissage compltant bien le premier ouvrage. [16] est un cours dUML 2.0 bien expliqu et plus complet et dtaill que [7] mais, en contrepartie, moins accessible. [3] constitue une approche pratique et critique dUML trs intressante. [25] 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 prolifique [23, 26, 24, 25] et comptant concernant la mise en uvre dUML. Agrable lire, [28] sintresse la place de linformatique dans notre socit et plus particulirement dans lentreprise. Enfin, 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 [21] ou encore le site [9].

Table des matiresy

y

Chapitre 1 Introduction la modlisation objet o 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 o 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 o 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 o 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 ? Chapitre 2 Diagramme de cas dutilisation o 2.1 Introduction o 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 o 2.3 Relations dans les diagrammes de cas dutilisation 2.3.1 Relations entre acteurs et cas dutilisation 2.3.2 Relations entre cas dutilisation 2.3.3 Relations entre acteurs2

y

y

2.4 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 o 2.5 Modlisation des besoins avec UML 2.5.1 Comment identifier les acteurs ? 2.5.2 Comment recenser les cas dutilisation ? 2.5.3 Description textuelle des cas dutilisation 2.5.4 Remarques Chapitre 3 Diagramme de classes o 3.1 Introduction o 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 o 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 Qualification 3.3.7 Classe-association 3.3.8 Agrgation et composition 3.3.9 Gnralisation et Hritage 3.3.10 Dpendance o 3.4 Interfaces o 3.5 Diagramme dobjets 3.5.1 Prsentation 3.5.2 Reprsentation 3.5.3 Relation de dpendance dinstanciation o 3.6 laboration et implmentation dun diagramme de classes 3.6.1 laboration dun diagramme de classes 3.6.2 Implmentation en Java 3.6.3 Implmentation en SQL Chapitre 4 Object constraint langage (OCL) o 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 prdfinies o 4.2 Intrt dOCL 4.2.1 OCL Introduction 4.2.2 Illustration par lexemple o 4.3 Typologie des contraintes OCLo

3

y

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 Dfinition dattributs et de mthodes (def et letin) 4.3.7 Initialisation (init) et volution des attributs (derive) o 4.4 Types et oprations utilisables dans les expressions OCL 4.4.1 Types et oprateurs prdfinis 4.4.2 Types du modle UML 4.4.3 OCL est un langage typ 4.4.4 Collections o 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 qualifie 4.5.4 Navigation vers une classe association 4.5.5 Navigation depuis une classe association 4.5.6 Accder une caractristique redfinie (oclAsType()) 4.5.7 Oprations prdfinies sur tous les objets 4.5.8 Opration sur les classes o 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 o 4.7 Exemples de contraintes Chapitre 5 Diagramme dtats-transitions o 5.1 Introduction au formalisme 5.1.1 Prsentation 5.1.2 Notion dautomate tats finis 5.1.3 Diagrammes dtats-transitions o 5.2 tat 5.2.1 Les deux acceptions du terme tat 5.2.2 tat initial et final o 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) o 5.4 Transition 5.4.1 Dfinition et syntaxe 5.4.2 Condition de garde 5.4.3 Effet dune transition 5.4.4 Transition externe 5.4.5 Transition dachvement 5.4.6 Transition interne o 5.5 Point de choix 5.5.1 Point de jonction 5.5.2 Point de dcision

4

y

y

y

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 Chapitre 6 Diagramme dactivits o 6.1 Introduction au formalisme 6.1.1 Prsentation 6.1.2 Utilisation courante o 6.2 Activit et Transition 6.2.1 Action 6.2.2 Activit 6.2.3 Groupe dactivits 6.2.4 N ud dactivit 6.2.5 Transition o 6.3 N ud excutable 6.3.1 N ud daction 6.3.2 N ud dactivit structure o 6.4 N ud de contrle 6.4.1 N ud initial 6.4.2 N ud final 6.4.3 N ud de dcision et de fusion 6.4.4 N ud de bifurcation et dunion o 6.5 N ud 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 N ud tampon central 6.5.6 N ud de stockage des donnes o 6.6 Partitions o 6.7 Exceptions Chapitre 7 Diagrammes dinteraction o 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 o 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 o 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 Chapitre 8 Diagrammes de composants et de dploiement o 8.1 Introductiono

5

y

8.2 Diagrammes de composants 8.2.1 Pourquoi des composants ? 8.2.2 Notion de composant 8.2.3 Notion de port 8.2.4 Diagramme de composants o 8.3 Diagramme de dploiement 8.3.1 Objectif du diagramme de dploiement 8.3.2 Reprsentation des n uds 8.3.3 Notion dartefact (artifact) 8.3.4 Diagramme de dploiement Chapitre 9 Mise en uvre dUML o 9.1 Introduction 9.1.1 UML nest pas une mthode 9.1.2 Une mthode simple et gnrique o 9.2 Identification des besoins 9.2.1 Diagramme de cas dutilisation 9.2.2 Diagrammes de squence systme 9.2.3 Maquette de lIHM o 9.3 Phases danalyse 9.3.1 Modle du domaine 9.3.2 Diagramme de classes participantes 9.3.3 Diagrammes dactivits de navigation o 9.4 Phase de conception 9.4.1 Diagrammes dinteraction 9.4.2 Diagramme de classes de conceptiono

Chapitre 1 Introduction la modlisation objet1.1 Le gnie logiciel1.1.1 LinformatisationLinformatisation 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 c ur 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 effet, depuis quelques annes, la fabrication du matriel est assure par quelques fabricants seulement. Ce matriel est relativement fiable et le march est standardis. Les problmes lis linformatique sont essentiellement des problmes de logiciel.

1.1.2 Les logiciels

6

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 8 380 applications, cette tude tablissait que :y y y

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, 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 logicielLe gnie logiciel est un domaine de recherche qui a t dfini (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 fiable, dautre part, il tait incroyablement difficile 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 fin des annes 1970. Cette crise de lindustrie du logiciel tait principalement due :y y y y y

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 budget total dun logiciel est affect la maintenance. Ce cot est rparti comme suit :y y

34% maintenance volutive (modification des spcifications initiales) ; 10% maintenance adaptative (nouvel environnement, nouveaux utilisateurs) ;7

y y y y y y

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.

Pour apporter une rponse tous ces problmes, le gnie logiciel sintresse particulirement la manire dont le code source dun logiciel est spcifi puis produit. Ainsi, le gnie logiciel touche au cycle de vie des logiciels :y y y y y y

lanalyse du besoin, llaboration des spcifications, la conceptualisation, le dveloppement, la phase de test, 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 logicielEn gnie logiciel, divers travaux ont men la dfinition 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, dfinies par le cahier des charges et les spcifications. 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 modification 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. Efficacit : Utilisation optimales des ressources matrielles. Portabilit : facilit avec laquelle un logiciel peut tre transfr sous diffrents environnements matriels et logiciels. Vrifiabilit : facilit de prparation des procdures de test. Intgrit : aptitude dun logiciel protger son code et ses donnes contre des accs non autoriss. Facilit demploi :8

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 seffectuer en fonction du contexte. 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. 3 c.f. section 1.2.1 > 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.

1.2 Modlisation, cycles de vie et mthodes1.2.1 Pourquoi et comment modliser ?Quest-ce quun modle ? Un modle est une reprsentation abstraite et simplifie (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 ninfluencent pas son comportement de manire significative. Il reflte 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 : 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 dfinit la composition dun panel dune population et son comportement, dans le but de fiabiliser 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 :y

plans dimplantation du btiment dans son environnement ;9

y y y y

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 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 diffrentes parties prenantes (notamment entre la matrise douvrage et la matrise d uvre 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 aller-retours entre le code et le modle sans perte dinformation. Le modle est enfin indispensable pour assurer un bon niveau de qualit et une maintenance efficace. En effet, 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 influence 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 d uvre 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 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 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 d uvre peut travailler dans de bonnes conditions. Lorsque cette professionnalisation a lieu, elle modifie 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 bnfices. Matrise douvrage et matrise d uvre Matre douvrage (MOA) :10

Le MOA est une personne morale (entreprise, direction etc.), une entit de lorganisation. Ce nest jamais une personne. Matre d uvre (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 dfinie 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 fixs 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 vrifications ncessaires ( recette usine ).

1.2.2 Le cycle de vie dun logicielLe 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 dfinir des jalons intermdiaires permettant la validation du dveloppement logiciel, 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 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 : Dfinition des objectifs Cet tape consiste dfinir la finalit 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. Spcifications ou conception gnrale Il sagit de llaboration des spcifications de larchitecture 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 programmation des fonctionnalits dfinies lors de phases de conception. Tests unitaires Ils permettent de vrifier individuellement que chaque sous-ensemble du logiciel est implment conformment aux spcifications.11

Intgration Lobjectif est de sassurer de linterfaage des diffrents lments (modules) du logiciel. Elle fait lobjet de tests dintgration consigns dans un document. Qualification (ou recette) Cest--dire la vrification de la conformit du logiciel aux spcifications 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 logicielModle de cycle de vie en cascade

Figure 1.1: Modle du cycle de vie en cascade

12

Le modle de cycle de vie en cascade (cf. figure 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 dfinis 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 insuffisant. Linconvnient majeur du modle de cycle de vie en cascade est que la vrification 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

Figure 1.2: Modle du cycle de vie en V

Le modle en V (cf. figure 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 effectus 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. Ceci rend explicite la prparation des dernires phases (validation-vrification) par les premires (construction du logiciel), et permet ainsi dviter un cueil bien connu de la spcification du logiciel : noncer une proprit quil est impossible de vrifier objectivement aprs la ralisation.13

Cependant, ce modle souffre toujours du problme de la vrification 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 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 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 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. Chaque incrment est dvelopp selon lun des modles prcdents. Les avantages de ce type de modle sont les suivants :y y y y

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 leffort de dveloppement grce la possibilit de recouvrement (paralllisation) des diffrentes phases.

Les risques de ce type de modle sont les suivants :y y

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 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 conceptionLes mthodes danalyse et de conception fournissent une mthodologie et des notations standards qui aident concevoir des logiciels de qualit. Il existe diffrentes manires pour classer ces mthodes, dont : La distinction entre composition et dcomposition :14

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 qualifie de structure) un systme est vu comme un ensemble hirarchique dunits en interaction, ayant chacune une fonction clairement dfinie. 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.3 De la programmation structure lapproche oriente objet1.3.1 Mthodes fonctionnelles ou structures

Figure 1.3: Reprsentation graphique dune approche fonctionnelle

Les mthodes fonctionnelles (galement qualifies 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 raffinements successifs pour produire des spcifications 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, 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. figure 1.3). Lapproche fonctionnelle dissocie le problme de la reprsentation des donnes, du problme du traitement de ces donnes. Sur la figure 1.3, les donnes du problme sont reprsentes sur la 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 dans une base de donnes), ou peut tre ralis par le passage de paramtre depuis le programme principal.

15

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 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 objetLapproche oriente objet considre le logiciel comme une collection dobjets dissocis, identifis 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 diffrents 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 identifiant 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 modifier. La difficult 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 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 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 diffrence entre une approche fonctionnelle et une approche objet nest donc pas dordre logique, mais pratique.16

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 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 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 modification aux donnes, 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. Dans une approche structure, lvolution des besoins entrane souvent une dgnrescence, ou une profonde remise en question, de la topologie typique de la figure 1.3 car la dcomposition des units de traitement (du programme principal aux sous-fonctions) est directement dicte par ces besoins. Dautre part, une modification des donnes entrane gnralement une modification dun nombre important de fonctions parpilles et difficiles identifier 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 diffrents de ceux manant de lapproche structure. Les units de traitement, et surtout leur dpendance dans la topologie de la figure 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 effet un changement de lattitude mentale du programmeur.

1.3.4 Concepts importants de lapproche objetDans 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 spcifiques 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 dfinissant une interface. Linterface est la vue externe dun objet, elle dfinit les services accessibles (offerts) aux utilisateurs de lobjet.17

Lencapsulation facilite lvolution dune application car elle stabilise lutilisation des objets : on peut modifier limplmentation des attributs dun objet sans modifier son interface, et donc la faon dont lobjet est utilis. 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, afin dy ajouter des caractristiques spcifiques ou den adapter certaines. Plusieurs classes peuvent tre gnralises en une classe qui les factorise, afin 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 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 des composants de lautre classe. Une relation dagrgation permet donc de dfinir des objets composs dautres objets. Lagrgation permet donc dassembler des objets de base, afin de construire des objets plus complexes.

1.3.5 Historique la programmation par objetsLes 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.4 UML1.4.1 IntroductionLa description de la programmation par objets a fait ressortir ltendue du travail conceptuel ncessaire : dfinition 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 dfinissant les modules et tapes18

de la ralisation. Cest cette dmarche antrieure lcriture que lon appelle modlisation ; son produit est un modle. Les spcifications fournies par la matrise douvrage en programmation imprative taient souvent floues : 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 objetsLes 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 :y y y

OMT de James Rumbaugh (General Electric) fournit une reprsentation graphique des aspects statique, dynamique et fonctionnel dun systme ; OOD de Grady Booch, dfinie 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 dfinir une mthode commune qui fdrerait leurs apports respectifs (on les surnomme depuis the Amigos ). UML (Unified Modeling Language) est n de cet effort de convergence. Ladjectif unified est l pour marquer quUML unifie, et donc remplace. En fait, et comme son nom lindique, UML na pas lambition dtre exactement une mthode : cest un langage. Lunification a progress par tapes. En 1995, Booch et Rumbaugh (et quelques autres) se sont mis daccord pour construire une mthode unifie, Unified 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 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 des systmes dinformation objets. La version dUML en cours en 2008 est UML 2.1.1 et les travaux damlioration se poursuivent. 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.19

1.4.3 UML en uvreUML 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 raison de la diversit des cas particuliers. Ils ont prfr se borner dfinir 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)

y y y y y y

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) o diagramme de squence (Sequence diagram) o diagramme de communication (Communication diagram) o diagramme global dinteraction (Interaction overview diagram) o diagramme de temps (Timing diagram)

y y y y

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 d uvre qui ils permettent de formaliser les contraintes de la ralisation et la solution technique. Diagramme de cas dutilisation

20

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 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 vrifier ladquation dun diagramme de classes diffrents 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 n uds 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 diffrentes 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. Prsentation des processus de travail par lesquels la stratgie entend se raliser :21

pour permettre au lecteur de voir comment lapplication va fonctionner en pratique, elle doit tre illustre par 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, sous les 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 de le prsenter sur lIntranet de lentreprise. En effet, 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. 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 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 spcifications UML, MOF, CORBA et IDL. LOMG est aussi lorigine de la recommandation MDA

Chapitre 2 Diagramme de cas dutilisation (Use Case Diagram)2.1 IntroductionBien 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 sous-systme, 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.2 lments des diagrammes de cas dutilisation2.2.1 Acteur

22

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 (figure 2.1) avec son nom (i.e. son rle) inscrit dessous.

Figure 2.1: Exemple de reprsentation dun acteur Il est galement possible de reprsenter un acteur sous la forme dun classeur (cf. section 2.4.3) strotyp (cf. section 2.4.4) > (figure 2.2).

Figure 2.2: Exemple de reprsentation dun acteur sous la forme dun classeur

2.2.2 Cas dutilisationUn 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 fin, 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 (figure 2.3) contenant le nom du cas (un verbe linfinitif), et optionnellement, au-dessus du nom, un strotype (cf. section 2.4.4).

Figure 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 > (figure 2.4). Nous reviendrons sur les notions dattributs ou dopration lorsque nous aborderons les diagrammes de classes et dobjets (section 3).

23

Figure 2.4: Exemple de reprsentation dun cas dutilisation sous la forme dun classeur

2.2.3 Reprsentation dun diagramme de cas dutilisation

Figure 2.5: Exemple simplifi de diagramme de cas dutilisation modlisant une borne daccs une banque. Comme le montre la figure 2.5, la frontire du systme est reprsente par un cadre. Le nom du systme figure lintrieur du cadre, en haut. Les acteurs sont lextrieur et les cas dutilisation lintrieur.

2.3 Relations dans les diagrammes de cas dutilisation2.3.1 Relations entre acteurs et cas dutilisationRelation dassociation

Figure 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 dutilisation et est reprsent un trait continu (cf. figure 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 * signifie plusieurs (figure 2.6), exactement n scrit tout simplement n, n..m signifie entre n et m, etc. Prciser une multiplicit sur une relation nimplique pas ncessairement que les cas sont utiliss en mme temps.

24

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. Acteurs principaux et secondaires Un acteur est qualifi de principal pour un cas dutilisation lorsque ce cas rend service cet acteur. 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 quun acteur secondaire est sollicit pour des informations complmentaires. En gnral, lacteur principal initie le cas dutilisation par ses sollicitations. Le strotype > vient orner lassociation reliant un cas dutilisation son acteur principal, le strotype > est utilis pour les acteurs secondaires (figure 2.6). Cas dutilisation interne Quand un cas nest pas directement reli un acteur, il est qualifi de cas dutilisation interne.

2.3.2 Relations entre cas dutilisation

Figure 2.7: Exemple de diagramme de cas dutilisation Types et reprsentations Il existe principalement deux types de relations :

25

y y

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 flche avec un trait pointill (figure 2.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 une flche avec un trait plein dont la pointe est un triangle ferm dsignant le cas le plus gnral (figure 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 > (figure 2.7). Par exemple, laccs aux informations dun compte bancaire inclut ncessairement une phase dauthentification avec un identifiant et un mot de passe (figure 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 Sauthentifier de la figure 2.7). Les inclusions permettent galement de dcomposer un cas complexe en sous-cas plus simples (figure 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.

Figure 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 artifices dinformaticiens.

26

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 > (figure 2.7). Lextension peut intervenir un point prcis du cas tendu. Ce point sappelle le point dextension. Il porte un nom, qui figure 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 figure 2.7 prsente lexemple dune banque o la vrification 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 figure 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 acteursLa 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 flche 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 figure 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.

Figure 2.9: Relations entre acteurs

2.4 Notions gnrales du langage UMLLes lments du langage UML que nous abordons ici ne sont pas spcifiques au diagramme de cas dutilisation mais sont gnraux. Nous avons dj utilis certains de ces lments dans ce chapitre et nous27

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

2.4.1 Paquetage

Figure 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 (figure 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 (figure 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 diffrents ou dvelopps par des quipes diffrentes. Il existe un paquetage racine unique, ventuellement anonyme, qui contient la totalit des modles dun systme.

2.4.2 Espace de nomsLes espaces de noms sont des paquetages, des classeurs, etc. On peut dterminer un lment nomm de faon unique par son nom qualifi, 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 qualifi, 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 ClasseurLes 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. des oprations), de relations et dune structure interne facultative. Il peut participer des relations dassociation, de gnralisation, de dpendance28

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 n uds, les composants, les sous-systmes, etc. Le type de classeur le plus important tant, bien videmment, la classe (cf. section 3).

2.4.4 StrotypeUn strotype est une annotation sappliquant sur un lment de modle. Il na pas de dfinition 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 figure 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 >.

2.4.5 Note

Figure 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. Si elle dcrit plusieurs lments, on dessine une ligne vers chacun dentre eux. Lexemple de la figure 2.11 montre une note exprimant une contrainte (cf. section 4.1) sur un attribut.1 Certains lments, comme les associations, peuvent avoir des instances bien quils ne soient pas reprsents dans des classeurs.

2.5 Modlisation des besoins avec UML2.5.1 Comment identifier les acteurs ?UML nemploie pas le terme dutilisateur mais dacteur. Les acteurs dun systme sont les entits externes ce systme qui interagissent (saisie de donnes, rception dinformation, ) avec lui. Les acteurs sont donc lextrieur du systme et dialoguent avec lui. Ces acteurs permettent de cerner linterface que le systme29

va devoir offrir son environnement. Oublier des acteurs ou en identifier de faux conduit donc ncessairement se tromper sur linterface et donc la dfinition du systme produire. Il faut faire attention ne pas confondre acteurs et utilisateurs (utilisateur avec le sens de la personne physique qui va appuyer sur un bouton) dun systme. Dune part parce que les acteurs inclus les utilisateurs humains mais aussi les autres systmes informatiques ou hardware qui vont communiquer avec le systme. Dautre part parce quun acteur englobe tout une classe dutilisateur. Ainsi, plusieurs utilisateurs peuvent avoir le mme rle, et donc correspondre un mme acteur, et une mme personne physique peut jouer des rles diffrents vis--vis du systme, et donc correspondre plusieurs acteurs. Chaque acteur doit tre nomm. Ce nom doit reflter sont rle car un acteur reprsente un ensemble cohrent de rles jous vis--vis du systme. Pour trouver les acteurs dun systme, il faut identifier quels sont les diffrents rles que vont devoir jouer ses utilisateurs (ex : responsable clientle, responsable dagence, administrateur, approbateur, ). Il faut galement sintresser aux autres systmes avec lesquels le systme va devoir communiquer comme :y y y

les priphriques manipuls par le systme (imprimantes, hardware dun distributeur de billet, ) ; des logiciels dj disponibles intgrer dans le projet ; des systmes informatiques externes au systme mais qui interagissent avec lui, etc.

Pour faciliter la recherche des acteurs, on peut imaginer les frontires du systme. Tout ce qui est lextrieur et qui interagit avec le systme est un acteur, tout ce qui est lintrieur est une fonctionnalit raliser. Vrifiez que les acteurs communiquent bien directement avec le systme par mission ou rception de messages. Une erreur frquente consiste rpertorier en tant quacteur des entits externes qui ninteragissent pas directement avec le systme, mais uniquement par le biais dun des vritables acteurs. Par exemple, lhtesse de caisse dun magasin de grande distribution est un acteur pour la caisse enregistreuse, par contre, les clients du magasins ne correspondent pas un acteur car ils ninteragissent pas directement avec la caisse.

2.5.2 Comment recenser les cas dutilisation ?Lensemble des cas dutilisation doit dcrire exhaustivement les exigences fonctionnelles du systme. Chaque cas dutilisation correspond donc une fonction mtier du systme, selon le point de vue dun de ses acteurs. Aussi, pour identifier les cas dutilisation, il faut se placer du point de vue de chaque acteur et dterminer comment et surtout pourquoi il se sert du systme. Il faut viter les redondances et limiter le nombre de cas en se situant un bon niveau dabstraction. Trouver le bon niveau de dtail pour les cas dutilisation est un problme difficile qui ncessite de lexprience. Nommez les cas dutilisation avec un verbe linfinitif suivi dun complment en vous plaant du point de vue de lacteur et non pas de celui du systme. Par exemple, un distributeur de billets aura probablement un cas dutilisation Retirer de largent et non pas Distribuer de largent. De par la nature fonctionnelle, et non objet, des cas dutilisation, et en raison de la difficult de trouver le bon niveau de dtail, il faut tre trs vigilant pour ne pas retomber dans une dcomposition fonctionnelle descendante hirarchique. Un nombre trop important de cas dutilisation est en gnral le symptme de ce type derreur.

30

Dans tous les cas, il faut bien garder lesprit quil ny a pas de notion temporelle dans un diagramme de cas dutilisation.

2.5.3 Description textuelle des cas dutilisationLe diagramme de cas dutilisation dcrit les grandes fonctions dun systme du point de vue des acteurs, mais nexpose pas de faon dtaille le dialogue entre les acteurs et les cas dutilisation. Bien que de nombreux diagrammes dUML permettent de dcrire un cas, il est recommand de rdiger une description textuelle car cest une forme souple qui convient dans bien des situations. Une description textuelle couramment utilise se compose de trois parties. 1. La premire partie permet didentifier le cas, elle doit contenir les informations qui suivent. Nom : Utiliser une tournure linfinitif (ex : Rceptionner un colis). Objectif : Une description rsume permettant de comprendre lintention principale du cas dutilisation. Cette partie est souvent renseigne au dbut du projet dans la phase de dcouverte des cas dutilisation. Acteurs principaux : Ceux qui vont raliser le cas dutilisation (la relation avec le cas dutilisation est illustre par le trait liant le cas dutilisation et lacteur dans un diagramme de cas dutilisation) Acteurs secondaires : Ceux qui ne font que recevoir des informations lissue de la ralisation du cas dutilisation Dates : Les dates de crations et de mise jour de la description courante. Responsable : Le nom des responsables. Version : Le numro de version. 2. La deuxime partie contient la description du fonctionnement du cas sous la forme dune squence de messages changs entre les acteurs et le systme. Elle contient toujours une squence nominale qui dcrit de droulement normal du cas. la squence nominale sajoutent frquemment des squences alternatives (des embranchement dans la squence nominale) et des squences dexceptions (qui interviennent quand une erreur se produit). Les prconditions : elles dcrivent dans quel tat doit tre le systme (lapplication) avant que ce cas dutilisation puisse tre dclench. Des scnarii : Ces scnarii sont dcrits sous la forme dchanges dvnements entre lacteur et le systme. On distingue le scnario nominal, qui se droule quand il ny a pas derreur, des scnarii alternatifs qui sont les variantes du scnario nominal et enfin les scnarii dexception qui dcrivent les cas derreurs. Des postconditions : Elle dcrivent ltat du systme lissue des diffrents scnarii. 3. La troisime partie de la description dun cas dutilisation est une rubrique optionnelle. Elle contient gnralement des spcifications non fonctionnelles (spcifications techniques, ). Elle peut ventuellement contenir une description des besoins en termes dinterface graphique.31

2.5.4 RemarquesConcernant les relations dans les cas dutilisation Il est important de noter que lutilisation des relations nest pas primordiale dans la rdaction des cas dutilisation et donc dans lexpression du besoin. Ces relations peuvent tre utiles dans certains cas mais une trop forte focalisation sur leur usage conduit souvent une perte de temps ou un usage fauss, pour une valeur ajoute, au final, relativement faible. Concernant les cas dutilisation Unanimement reconnus comme cantonns lingnierie des besoins, les diagrammes de cas dutilisation ne peuvent tre qualifis de modlisation proprement parler. Dailleur, de nombreux lments descriptifs sont en langage naturel. De plus, ils ne correspondent pas stricto sensu une approche objet. En effet, capturer les besoins, les dcouvrir, les rfuter, les consolider, etc., correspond plus une analyse fonctionnelle classique. Les Use case Realization UML ne mentionne que le fait que la ralisation dun cas dutilisation est dcrit par une suite de collaborations entre lments de modlisation mais ne parle par de llment de modlisation use case realization. Les use case realization ne sont pas un formalisme dUML mais du RUP (Rational Unified Process). Aprs avoir rdig les cas dutilisation, il faut identifier des objets, des classes, des donnes et des traitements qui vont permettre au systme de supporter ces cas dutilisation. Pour documenter la manire dont sont mis en uvre les cas dutilisation du systme, on peut utiliser le mcanisme des use case realization. Ils permettent de regrouper un diagramme de classes et des diagrammes dinteraction. On retrouvera dans le diagramme de classes les classes qui mettent en uvre le cas dutilisation associ au use case realization. On retrouvera dans les diffrents diagrammes dinteraction une documentation des diffrents vnements changs entre les objets afin de raliser les diffrents scnarii dcrit dans le cas dutilisation. Au final on aura un use case realization par cas dutilisation et dans chaque use case realization on aura autant de diagrammes dinteraction que ncessaire pour illustrer les scnarii dcrits dans le cas dutilisation (scnario nominal, scnarii alternatifs et scnarii dexception). Les use case realization permettent donc, dans la pratique, dapporter un lment de rponse la question : Comment structurer mon modle UML ?

Chapitre 3 Diagramme de classes (Class Diagram)3.1 IntroductionLe diagramme de classes est considr comme le plus important de la modlisation oriente objet, il est le seul obligatoire lors dune telle modlisation.32

Alors que le diagramme de cas dutilisation montre un systme du point de vue des acteurs, le diagramme de classes en montre la structure interne. Il permet de fournir une reprsentation abstraite des objets du systme qui vont interagir ensemble pour raliser les cas dutilisation. Il est important de noter quun mme objet peut trs bien intervenir dans la ralisation de plusieurs cas dutilisation. Les cas dutilisation ne ralisent donc pas une partition1 des classes du diagramme de classes. Un diagramme de classes nest donc pas adapt (sauf cas particulier) pour dtailler, dcomposer, ou illustrer la ralisation dun cas dutilisation particulier. Il sagit dune vue statique car on ne tient pas compte du facteur temporel dans le comportement du systme. Le diagramme de classes modlise les conceps du domaine dapplication ainsi que les concepts internes crs de toutes pices dans le cadre de limplmentation dune application. Chaque langage de Programmation Orient Objets donne un moyen spcifique dimplmenter le paradigme objet (pointeurs ou pas, hritage multiple ou pas, etc.), mais le diagramme de classes permet de modliser les classes du systme et leurs relations indpendamment dun langage de programmation particulier. Les principaux lments de cette vue statique sont les classes et leurs relations : association, gnralisation et plusieurs types de dpendances, telles que la ralisation et lutilisation. Une partition dun ensemble est un ensemble de parties non vides de cet ensemble, deux deux disjointes et dont la runion est gale lensemble.

3.2 Les classes3.2.1 Notions de classe et dinstance de classeUne instance est une concrtisation dun concept abstrait. Par exemple :y y

la Ferrari Enzo qui se trouve dans votre garage est une instance du concept abstrait Automobile ; lamiti qui lie Jean et Marie est une instance du concept abstrait Amiti ;

Une classe est un concept abstrait reprsentant des lments varis comme :y y y y y

des lments concrets (ex : des avions), des lments abstraits ( ex : des commandes de marchandises ou services), des composants dune application (ex : les boutons des botes de dialogue), des structures informatiques (ex : des tables de hachage), des lments comportementaux (ex : des tches), etc.

Tout systme orient objet est organis autour des classes. Une classe est la description formelle dun ensemble dobjets ayant une smantique et des caractristiques communes. Un objet est une instance dune classe. Cest une entit discrte dote dune identit, dun tat et dun comportement que lon peut invoquer. Les objets sont des lments individuels dun systme en cours dexcution. Par exemple, si lon considre que Homme (au sens tre humain) est un concept abstrait, on peut dire que la personne Marie-Ccile est une instance de Homme. Si Homme tait une classe, Marie-Ccile en serait une instance : un objet.

3.2.2 Caractristiques dune classe33

Une classe dfinit un jeu dobjets dots de caractristiques communes. Les caractristiques dun objet permettent de spcifier son tat et son comportement. Dans les sections 1.3.2 et 1.3.4, nous avons dit que les caractristiques dun objet taient soit des attributs, soit des oprations. Ce nest pas exact dans un diagramme de classe car les terminaisons dassociations sont des proprits qui peuvent faire partie des caractristiques dun objet au mme titre que les attributs et les oprations (cf. section 3.3.2). tat dun objet : Ce sont les attributs et gnralement les terminaisons dassociations, tous deux runis sous le terme de proprits structurelles, ou tout simplement proprits2, qui dcrivent ltat dun objet. Les attributs sont utiliss pour des valeurs de donnes pures, dpourvues didentit, telles que les nombres et les chanes de caractres. Les associations sont utilises pour connecter les classes du diagramme de classe ; dans ce cas, la terminaison de lassociation (du ct de la classe cible) est gnralement une proprit de la classe de base (cf. section 3.3.1 et 3.3.2). Les proprits dcrites par les attributs prennent des valeurs lorsque la classe est instancie. Linstance dune association est appele un lien. Comportement dun objet : Les oprations dcrivent les lments individuels dun comportement que lon peut invoquer. Ce sont des fonctions qui peuvent prendre des valeurs en entre et modifier les attributs ou produire des rsultats. Une opration est la spcification (i.e. dclaration) dune mthode. Limplmentation (i.e. dfinition) dune mthode est galement appele mthode. Il y a donc une ambigut sur le terme mthode. Les attributs, les terminaisons dassociation et les mthodes constituent donc les caractristiques dune classe (et de ses instances).

3.2.3 Reprsentation graphique

Figure 3.1: Reprsentation UML dune classe

Une classe est un classeur 3. Elle est reprsente par un rectangle divis en trois cinq compartiments (figure 3.1). Le premier indique le nom de la classe (cf. section 3.2.5), le deuxime ses attributs (cf. section 3.2.6) et le troisime ses oprations (cf. section 3.2.7). Un compartiment des responsabilits peut tre ajout pour numrer lensemble de tches devant tre assures par la classe mais pour lesquelles on ne dispose pas encore assez dinformations. Un compartiment des exceptions peut galement tre ajout pour numrer les situations exceptionnelles devant tre gres par la classe.

3.2.4 Encapsulation, visibilit, interface

34

Figure 3.2: Bonnes pratiques concernant la manipulation des attributs. Nous avons dj abord cette problmatique section 1.3.4. Lencapsulation est un mcanisme consistant rassembler les donnes et les mthodes au sein dune structure en cachant limplmentation de lobjet, cest-dire en empchant laccs aux donnes par un autre moyen que les services proposs. Ces services accessibles (offerts) aux utilisateurs de lobjet dfinissent ce que lon appel linterface de lobjet (sa vue externe). Lencapsulation permet donc de garantir lintgrit des donnes contenues dans lobjet. Lencapsulation permet de dfinir des niveaux de visibilit des lments dun conteneur. La visibilit dclare la possibilit pour un lment de modlisation de rfrencer un lment qui se trouve dans un espace de noms diffrents de celui de llment qui tablit la rfrence. Elle fait partie de la relation entre un lment et le conteneur qui lhberge, ce dernier pouvant tre un paquetage, une classe ou un autre espace de noms. Il existe quatre visibilits prdfinies. Public ou + : tout lment qui peut voir le conteneur peut galement voir llment indiqu. Protected ou # : seul un lment situ dans le conteneur ou un de ses descendants peut voir llment indiqu. Private ou - : seul un lment situ dans le conteneur peut voir llment. Package ou ou rien : seul un lment dclar dans le mme paquetage peut voir llment. Par ailleur, UML 2.0 donne la possibilit dutiliser nimporte quel langage de programmation pour la spcification de la visibilit. Dans une classe, le marqueur de visibilit se situe au niveau de chacune de ses caractristiques (attributs, terminaisons dassociation et opration). Il permet dindiquer si une autre classe peut y accder. Dans un paquetage, le marqueur de visibilit se situe sur des lments contenus directement dans le paquetage, comme les classes, les paquetages imbriqus, etc. Il indique si un autre paquetage susceptible daccder au premier paquetage peut voir les lments. Dans la pratique, lorsque des attributs doivent tre accessibles de lextrieur, il est prfrable que cet accs ne soit pas direct mais se fasse par lintermdiaire doprations (figure 3.2).

3.2.5 Nom dune classeLe nom de la classe doit voquer le concept dcrit par la classe. Il commence par une majuscule. On peut ajouter des informations subsidiaires comme le nom de lauteur de la modlisation, la date, etc. Pour indiquer quune classe est abstraite, il faut ajouter le mot-clef abstract.35

La syntaxe de base de la dclaration dun nom dune classe est la suivante :[ ::...:: ] [ { [abstract], [], [], ... } ] Mta-langage des syntaxes

Nous aurons rgulirement recours ce mta-langage pour dcrire des syntaxes de dclaration. Ce mtalangage contient certains mta-caractres :[ ]:

les crochets indiquent que ce qui est lintrieur est optionnel ;< >:

les signes infrieur et suprieur indiquent que ce qui est lintrieur est plus ou moins libre ; par exemple, la syntaxe de dclaration dune variable comme compteur : int est : ; :

les cotes sont utiles quand on veut utiliser un mta-caractre comme un caractre ; par exemple, pour dsigner un crochet ([) il faut crire [ car [ est un mta-caractre ayant une signification spciale ;... :

Permet de dsigner une suite de squence de longueur non dfinie, le contexte permettant de comprendre de quelle suite il sagit.

3.2.6 Les attributsAttributs de la classe Les attributs dfinissent des informations quune classe ou un objet doivent connatre. Ils reprsentent les donnes encapsules dans les objets de cette classe. Chacune de ces informations est dfinie par un nom, un type de donnes, une visibilit et peut tre initialis. Le nom de lattribut doit tre unique dans la classe. La syntaxe de la dclaration dun attribut est la suivante : [/] : [ '['']' [{}] ] [ = ]

Le type de lattribut () peut tre un nom de classe, un nom dinterface ou un type de donn prdfini. La multiplicit () dun attribut prcise le nombre de valeurs que lattribut peut contenir. Lorsquune multiplicit suprieure 1 est prcise, il est possible dajouter une contrainte ({}) pour prciser si les valeurs sont ordonnes ({ordered}) ou pas ({list}). Attributs de classe Par dfaut, chaque instance dune classe possde sa propre copie des attributs de la classe. Les valeurs des attributs peuvent donc diffrer dun objet un autre. Cependant, il est parfois ncessaire de dfinir un attribut de classe (static en Java ou en C++) qui garde une valeur unique et partage par toutes les instances de la classe. Les instances ont accs cet attribut mais nen possdent pas une copie. Un attribut de classe nest donc pas une proprit dune instance mais une proprit de la classe et laccs cet attribut ne ncessite pas lexistence dune instance. Graphiquement, un attribut de classe est soulign. Attributs drivs36

Les attributs drivs peuvent tre calculs partir dautres attributs et de formules de calcul. Lors de la conception, un attribut driv peut tre utilis comme marqueur jusqu ce que vous puissiez dterminer les rgles lui appliquer. Les attributs drivs sont symboliss par lajout dun / devant leur nom.

3.2.7 Les mthodesMthode de la classe Dans une classe, une opration (mme nom et mme types de paramtres) doit tre unique. Quand le nom dune opration apparat plusieurs fois avec des paramtres diffrents, on dit que lopration est surcharge. En revanche, il est impossible que deux oprations ne se distinguent que par leur valeur retourne. La dclaration dune opration contient les types des paramtres et le type de la valeur de retour, sa syntaxe est la suivante : ([, ... , ]) : [] [{}]

La syntaxe de dfinition dun paramtre () est la suivante :[] : ['['']'] [=]

La direction peut prendre lune des valeurs suivante : in : Paramtre dentre pass par valeur. Les modifications du paramtre ne sont pas disponibles pour lappelant. Cest le comportement par dfaut. out : Paramtre de sortie uniquement. Il ny a pas de valeur dentre et la valeur finale est disponible pour lappelant. inout : Paramtre dentre/sortie. La valeur finale est disponible pour lappelant. Le type du paramtre () peut tre un nom de classe, un nom dinterface ou un type de donn prdfini. Les proprits () correspondent des contraintes ou des informations complmentaires comme les exceptions, les prconditions, les postconditions ou encore lindication quune mthode est abstraite (mot-clef abstract), etc. Mthode de classe Comme pour les attributs de classe, il est possible de dclarer des mthodes de classe. Une mthode de classe ne peut manipuler que des attributs de classe et ses propres paramtres. Cette mthode na pas accs aux attributs de la classe (i.e. des instances de la classe). Laccs une mthode de classe ne ncessite pas lexistence dune instance de cette classe. Graphiquement, une mthode de classe est souligne. Mthodes et classes abstraites37

Une mthode est dite abstraite lorsquon connat son entte mais pas la manire dont elle peut tre ralise (i.e. on connat sa dclaration mais pas sa dfinition). Une classe est dite abstraite lorsquelle dfinit au moins une mthode abstraite ou lorsquune classe parent (cf. section 3.3.9) contient une mthode abstraite non encore ralise. On ne peut instancier une classe abstraite : elle est voue se spcialiser (cf. section 3.3.9). Une classe abstraite peut trs bien contenir des mthodes concrtes. Une classe abstraite pure ne comporte que des mthodes abstraites. En programmation oriente objet, une telle classe est appele une interface. Pour indiquer quune classe est abstraite, il faut ajouter le mot-clef abstract derrire son nom.

3.2.8 Classe activeUne classe est passive par dfaut, elle sauvegarde les donnes et offre des services aux autres. Une classe active initie et contrle le flux dactivits. Graphiquement, une classe active est reprsente comme une classe standard dont les lignes verticales du cadre, sur les cts droit et gauche, sont doubles. 2 Il faut ici aborder un petit problme de terminologie autour du mot proprit. En effet, dans la littrature, le mot proprit est parfois utilis pour dsigner toutes les caractristiques dune classe (i.e. les attributs comme les mthodes). Dans ce cas, les attributs et les terminaisons dassociation sont rassembls sous le terme de proprits structurelles, le qualificatif structurelle prenant ici toute son importance. Dun autre ct, le mot proprit est souvent utilis dans lacception du terme anglais property (dans la norme UML Superstructure version 2.1.1), qui, lui, ne dsigne que les attributs et les terminaisons dassociation, cest--dire les proprits structurelles. Pour englober les mthodes, il faut alors utiliser le terme plus gnrique de caractristiques, qui prend ainsi le rle de traduction du terme anglais feature dans la norme. Dans le prsent cours, je mefforce de me conformer cette deuxime solution o proprit et proprit structurelle dsignent finalement la mme chose. 3 De manire gnrale, toute bote non strotype dans un diagramme de classes est implicitement une classe. Ainsi, le strotype class est le strotype par dfaut.

3.3 Relations entre classes3.3.1 Notion dassociationUne association est une relation entre deux classes (association binaire) ou plus (association n-aire), qui dcrit les connexions structurelles entre leurs instances. Une association indique donc quil peut y avoir des liens entr