UML2 Pour Les Developpeurs - Cours Avec Exercices Corriges

Xavier BlancIsabelle Mounieravec la contribution de Cdric Besse

UML2pour les

dveloppeursCours avec exercices corrigs

UML2pour lesdveloppeursCours avec exercices corrigs

Un cours dinitiation UML conu pour les dveloppeurs et les tudiants en informatiqueLa plupart des livres sur UML sadressent avant tout aux concepteurs et architectes logiciels, selon une dmarche tout-modle dans laquelle la production de code est traite comme une activit subalterne. Cette approche suscite videmment des rticenceschez les dveloppeurs et dconcerte les tudiants, dont la formation reste axe principalement sur la programmation et qui mesu-rent mal les enjeux du formalisme UML.

UML 2 pour les dveloppeurs prend le contre-pied de ces approches classiques. Louvrage montre comment articuler harmonieu-sement modlisation et programmation, en insistant sur les gains de productivit que permettent ces allers-retours entre lesmodles UML et le code.

Chaque notion UML importante est introduite par un exemple et chaque chapitre se clt par une srie dexercices corrigs (90au total), qui permettront au lecteur de tester ses connaissances.

Pour illustrer concrtement les relations entre code et modles, les auteurs font le choix du langage Java, les principes prsen-ts tant naturellement transposables dautres langages.

Au sommairePourquoi modliser Diagrammes de classes Reverse Engineering Rtroconception et patrons de conception (design patterns) Gnration de code Diagrammes de squence Diagrammes de squence de test Plates-formes dexcution Diagrammesde cas dutilisation Dveloppement avec UML Corrigs des exercices.

Sur le site www.editions-eyrolles.com Dialoguez avec les auteurs Tlchargez les modles et le code source des exemples du livre

97

82

21

21

20

29

5

Code

dite

ur :

G120

29

ISBN

: 2-

212-

1202

9-X

16,90

X.

Bla

nc

I. M

ounie

r

Xavier BlancMatre de confrences lUniversit Pierre et Marie Curie (Paris 6), Xavier Blanc est responsable de lenseigne-ment des techniques de modlisation en 3e anne de licence et en master dinformatique. Ses recherches portentdepuis 1998 sur lingnierie guide par les modles et il est le reprsentant du LIP6 (Laboratoire dinformatiquede lUniversit Paris 6) lOMG. Il est galement auteur de MDA en action, paru chez le mme diteur.

Isabelle MounierMatre de confrences lUniversit Pierre et Marie Curie, Isabelle Mounier enseigne principalement les tech-niques de dveloppement dapplications en licence dinformatique. Ses activits de recherche ont dabord portsur la vrification de proprits temporelles de systmes informatiques modliss par des rseaux de Petri etelle sintresse aujourdhui aux aspects formels des langages de modlisation tels quUML.

UM

L2po

ur l

esd

velo

ppeu

rsblanc 11/09/06 21:07 Page 1

mon mari Jean-Luc et mes fils Julien, Romain et Clment

Isabelle

ma femme Virginie, mes fils Arthur et Louis et au troisime venir

Xavier

Prface

UML est un langage de modlisation trs complet, qui couvre de nombreux aspects dudveloppement des logiciels, comme les exigences, larchitecture, les structures et lescomportements.Depuis sa normalisation, en 1997, UML a fortement volu, passant dun langage peuformel, principalement destin la documentation, un langage suffisamment prcispour que des applications puissent tre gnres partir des modles. Cette volutionvers une plus grande prcision a cependant cr une csure entre les tenants du tout-modle , qui demandent toujours plus de formalisme, et les dveloppeurs, qui appr-cient UML pour sa capacit capturer en quelques dessins les grandes lignes duneapplication.Le mieux tant lennemi du bien, pour satisfaire les uns, il a fallu complexifier UML au-del du besoin des autres. En pratique, leffort de formalisation et dabstraction requispar une utilisation complte du langage de modlisation peut souvent savrer contre-productif lorsque lcriture de code est lobjectif immdiat.Dans cet ouvrage, Xavier Blanc et Isabelle Mounier prsentent une approche de dvelop-pement de logiciels dans laquelle modlisation et programmation se compltent harmo-nieusement. Leur dmarche me semble trs pertinente, car elle permet aux dveloppeursde bnficier tout de suite dune large part des avantages de la modlisation avec UML,tout en restant dans le monde de la programmation. Loin de forcer les dveloppeurs migrer vers un tat desprit tout-modle , dans lequel la production de code appara-trait comme une activit subalterne, les auteurs nous montrent comment la modlisationet la programmation peuvent sutiliser de manire conjointe et complmentaire.UML pour le dveloppeur est le fruit de lexprience de Xavier et Isabelle, laconfluence des modles et du code. Leur approche pragmatique et leur dmarche mtho-dologique bien dfinie seront trs utiles aux dveloppeurs soucieux de concilier les vuesabstraites des modles avec du code concret, faisant directement partie de lapplication dvelopper.

Pierre-Alain MULLER, matre de confrences, Triskell INRIA Rennes

Remerciements

Nous tenons remercier ici tous ceux qui nous ont aids directement et indirectement rdiger cet ouvrage : Les tudiants de lUniversit Pierre et Marie Curie qui ont suivi cet enseignement lors

de sa mise en place. Lquipe pdagogique du module LI342, qui, par ses nombreuses remarques, a permis

damliorer le contenu de cet enseignement. Les membres des thmes Regal et Move du LIP6 pour nous avoir encourags tout au

long de ce projet. Frdric Vigouroux pour avoir attentivement relu les versions prliminaires de cet

ouvrage et y avoir apport son regard critique.

Avant-propos

UML (Unified Modeling Language) est aujourdhui le langage de modlisation dappli-cations informatiques le plus important du march. Il est support par la quasi-totalit desoutils de dveloppement, lesquels permettent ldition de modles UML et offrent descapacits telles que la gnration de code, de test et de documentation, le suivi dexigen-ces ou encore le Reverse Engineering.Pour autant, ce langage reste trs complexe et nest pas facile assimiler, surtout lorsquenous souhaitons obtenir rapidement un gain de productivit. La raison cela est quelapproche classique dutilisation dUML, que nous nommons UML pour larchitecte,vise surtout utiliser les modles UML comme des moyens de rflexion, dchange et decommunication entre les membres dune mme quipe de dveloppement. Cette appro-che suit toutes les phases du cycle de vie des applications. La gnration de code narrivealors qu la fin et nest rentable que si nous avons respect scrupuleusement toutes lesphases antrieures. La difficult de cet exercice nous fait mieux comprendre pourquoi lesgains de productivit ne sont que rarement obtenus.Une autre approche UML, que nous nommons UML pour le dveloppeur, est dj identi-fie par quelques outilleurs du march. Davantage adapte au dveloppeur quau travailen quipe, cette approche vise obtenir des gains de productivit trs rapidement. Lideprincipale la base de cette approche consiste effectuer des allers-retours entre modlesUML et code dans lobjectif dutiliser conjointement les meilleurs avantages de chacundes deux mondes (modle et code). Ainsi, lcriture dalgorithmes, la compilation etlexcution sont laisses au niveau des langages de programmation, tandis que ladcoupe en packages ou lapplication de patrons de conception seffectue au niveau desmodles UML. Des synchronisations sont effectues entre les modles et le code afindassurer une cohrence de lensemble. Cette approche trs pragmatique offre rapide-ment de forts gains de productivit.Ces deux approches opposes compliquent lapprentissage dUML pour toute personnedsireuse de savoir comment utiliser ce langage dans son propre contexte. De plus, tousles ouvrages existants adressent principalement lapproche UML pour larchitecte et nefont que peu de cas des mcanismes liant UML au code des applications. Ltudiant, toutcomme le dveloppeur de mtier, ne peuvent ds lors mesurer pleinement les avantagesde ce langage pour leur contexte, qui porte essentiellement sur le dveloppement du codedes applications.

UML pour les dveloppeursVIII

Cest pourquoi nous prsentons dans cet ouvrage un cours exclusivement ddi lapproche UML pour le dveloppeur. Notre objectif est de montrer la complmentaritque peut offrir UML nimporte quel langage de programmation. Nous prsentons danschaque cas les gains de productivit que nous pouvons en obtenir.

Une approche contre-piedLe droulement pdagogique de ce cours est volontairement contre-pied des coursUML classiques. Alors que ces derniers commencent invariablement par prsenter lesfameux diagrammes de cas dutilisation et finissent par la gnration de code, nousproposons linverse, en commenant par le code et en finissant par les diagrammes de casdutilisation. Notre objectif est de mettre au premier plan les mcanismes UML quioffrent directement des gains de productivit et den mesurer les impacts. Pour autant, lesprincipales notions UML auront t introduites et commentes la fin du cours.

Organisation de ce coursLe plan de ce cours est le suivant :

1. Un curieux besoin de modles : ce chapitre prsente les principaux avantages desmodles UML afin de bien faire comprendre les relations entre modle et code. Nousy dfinissons la notion de niveau dabstraction qui permet de reprsenter une mmeapplication suivant diffrentes vues.

2. Diagrammes de classes UML : ce chapitre prsente le plus employ des diagrammesUML. Ce chapitre nest pas un guide de rfrence du diagramme de classes. Nousprsentons les concepts ncessaires dans le contexte de ce cours.

3. Reverse Engineering : ce chapitre prsente les principes du Reverse Engineering, quiconsiste construire automatiquement un modle UML partir de code. Nous dfi-nissons un ensemble de rgles permettant de produire un diagramme de classes partir du code dune application.

4. Rtroconception et patrons de conception : ce chapitre prsente les oprations derestructuration dapplications effectuables sur des modles UML. Nous expliquons lerle des patrons de conception et comment les appliquer sur un diagramme de clas-ses.

5. Gnration de code : ce chapitre prsente les principes de la gnration de code partir de modles UML. Nous dfinissons un ensemble de rgles permettant de gn-rer du code partir dun diagramme de classes.

6. Diagrammes de squences : ce chapitre prsente les diagrammes de squence. Nousexpliquons en quoi ces diagrammes sont ncessaires pour mieux comprendre lecomportement dune application. Nous insistons sur le fait quils ne contiennent paslinformation ncessaire la gnration de code.

Avant-propos IX

7. Diagrammes de squences et tests : ce chapitre prsente lutilisation des diagrammesde squence pour la gnration de tests. Nous expliquons les principes du testdapplication et sa mise en uvre par lintermdiaire de diagrammes de squence detest.

8. UML et les plates-formes dexcution : ce chapitre prsente les relations entre UMLet les plates-formes dexcution afin de bien faire comprendre la capacit dabstrac-tion des modles UML. Nous insistons sur le fait quil est important, pour une mmeapplication, davoir des modles indpendants de la plate-forme dexcution etdautres plus troitement lis cette dernire.

9. Diagrammes de cas dutilisation : ce chapitre prsente les diagrammes de cas dutili-sation. Ils sont utiliss pour reprsenter les fonctionnalits dune application quel quesoit le niveau dabstraction considr.

10. Dveloppement avec UML : ce chapitre prsente une mthode de dveloppementavec UML permettant dobtenir lensemble des diagrammes ncessaires la repr-sentation dune application Nous partons cette fois de la description de lapplicationet nous expliquons lensemble des tapes suivre pour obtenir le code de lapplica-tion tout en ayant construit lensemble des diagrammes ncessaires pour faire le lienentre tous les niveaux dabstraction.

Pour rendre plus concrte les relations entre code et modle, nous avons choisi de baserce cours sur le langage Java. Tous les mcanismes de gnration de code ou de ReverseEngineering que nous prsentons sappuient donc sur Java. Les principes que nousprsentons dans ce cours sont cependant transposables vers dautres langages deprogrammation.

Chaque cours est suivi dun ensemble dexercices complmentaires du cours. Noussoulignons que la lecture de la partie cours uniquement ne permet pas daccder lensemble des informations prsentes dans ce livre.

qui sadresse ce cours ?Cet ouvrage sadresse principalement aux tudiants et aux dveloppeurs de mtier ayantdes connaissances en programmation par objets et dsireux de dcouvrir les bnfices dulangage UML pour le dveloppement dapplications. Il ne sagit pas dun guide de rf-rence sur UML.

Chaque notion importante dans le contexte du dveloppement avec UML est introduitepar un exemple, et chaque chapitre se clt par une srie dexercices (91 au total) aveccorrigs, qui permettront au lecteur de tester ses connaissances.

Louvrage sadresse aussi aux enseignants dsireux de transmettre les principes de basedes langages de modlisation selon une approche pragmatique, en liaison avec les techni-ques classiques de dveloppement dapplications.

Table des matiresPrface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IIIRemerciements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VAvant-propos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VII

Une approche contre-pied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VIIIOrganisation de ce cours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VIII qui sadresse ce cours ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IX

CHAPITRE 1

Un curieux besoin de modles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Construction dapplications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Le code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Les modles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

CHAPITRE 2

Diagrammes de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Vue structurelle du modle UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Paradigme orient objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Concepts lmentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Associations entre classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Concepts avancs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

CHAPITRE 3

Reverse Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Smantiques UML et Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Diffrences des smantiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

UML pour les dveloppeursXII

Synthse entre UML et les langages de programmation . . . . . . . . . . . . . . . 30Passage de code Java vers les diagrammes de classes . . . . . . . . . . . . . . 30

Rgles de correspondance du Reverse Engineering . . . . . . . . . . . . . . . . . . 32Intrt et limites du Reverse Engineering . . . . . . . . . . . . . . . . . . . . . . . . 34

Diagrammes faire aprs un Reverse Engineering . . . . . . . . . . . . . . . . . . . 35

CHAPITRE 4

Rtroconception et patrons de conception . . . . . . . . . . . . . . . . . . 39Identification des dpendances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Quest-ce quune dpendance ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Impact des cycles de dpendances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Casser les cycles de dpendances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Patron de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Le patron de conception Observer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

CHAPITRE 5

Gnration de code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51DUML Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51UML vers Java et Java vers UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Approches UML et code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Cycle de dveloppement UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

CHAPITRE 6

Diagrammes de squence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Vue comportementale du modle UML . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Concepts lmentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Le temps dans les diagrammes de squence . . . . . . . . . . . . . . . . . . . . . . . . 66

Liens avec la vue structurelle du modle . . . . . . . . . . . . . . . . . . . . . . . . . 68Objet et classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Diagramme et modle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Concepts avancs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Interactions et gnration de code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Fragment dinteraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Limites intrinsques des interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Table des matires XIII

CHAPITRE 7

Diagrammes de squence de test . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Les tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Comment utiliser les tests ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79criture de cas de test partir dun modle UML . . . . . . . . . . . . . . . . . 80

Cas de test abstrait et interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Cas de test excutables et interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

CHAPITRE 8

Plates-formes dexcution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Java dans UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Modles 100 % UML et modles UML pour Java . . . . . . . . . . . . . . . . . . . 87UML productif ou prenne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Niveaux conceptuel et physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Abstraction de la plate-forme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Niveaux dabstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Cycle de dveloppement UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Intgration des deux niveaux dans le cycle . . . . . . . . . . . . . . . . . . . . . . . . . 92Approches possibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

CHAPITRE 9

Diagrammes de cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Vue fonctionnelle du modle UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Fonctionnalits dune application oriente objet . . . . . . . . . . . . . . . . . . . . . 97Concepts lmentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Liens avec les autres parties du modle . . . . . . . . . . . . . . . . . . . . . . . . . . 100Concepts avancs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Concepts avancs relatifs aux cas dutilisation . . . . . . . . . . . . . . . . . . . . . . 101Concept avanc relatif aux acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

CHAPITRE 10

Dveloppement avec UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Analyse et conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Analyse du problme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Conception de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

UML pour les dveloppeursXIV

Comment passer du quoi au comment ? . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Mthode de dveloppement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

La mthode UML pour le dveloppeur . . . . . . . . . . . . . . . . . . . . . . . . . 115

CHAPITRE 11Corrigs des TD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

TD1. Un curieux besoin de modlisation . . . . . . . . . . . . . . . . . . . . . . . . . 123TD2. Diagrammes de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127TD3. Reverse Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136TD4. Rtroconception et patrons de conception . . . . . . . . . . . . . . . . . . . 141TD5. Gnration de code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146TD6. Diagrammes de squence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151TD7. Diagrammes de squence de test . . . . . . . . . . . . . . . . . . . . . . . . . . . 158TD8. Plates-formes dexcution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161TD9. Diagrammes de cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 166TD10. Dveloppement avec UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

ANNEXE 1

Code dun carnet dadresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

ANNEXE 2

Exemple de partiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193Questions de cours (4 points) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193Exercices (16 points) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

1Un curieux besoin de modles

Construction dapplicationsEn simplifiant lextrme, nous pourrions dire que la construction dune applicationinformatique se rsume raliser du code pour rpondre au besoin dun utilisateur, aussiappel client.La figure 1.1 illustre cette simplification en prenant lexemple de Word, qui a t conupour permettre, entre autres, ses utilisateurs dcrire des livres ou des lettres.

Objectifs Sensibiliser le lecteur la complexit intrinsque de la construction dapplications

informatiques

Motiver le besoin de modliser pour grer cette complexit et non la simplifier Comprendre la place du modle par rapport au code

Figure 1.1 Simplification extrme de la ralisation dune application informatique

Besoin

code

Avoir un logicielpour crire un livre

ou une lettre

Word

UML pour les dveloppeurs2

Cette simplification peut tre considre comme grossire. Elle a cependant le mrite debien rappeler la finalit de lactivit de construction dapplications informatiques, qui estde raliser le code.

Pour autant, la ralisation du code nest pas la seule activit effectuer lorsque noussouhaitons construire une application.

Parmi les autres activits non moins indispensables effectuer, citons notamment lessuivantes :

Sassurer davoir bien compris le besoin de lutilisateur afin de raliser un code qui lesatisfasse. Il ne faut pas se mettre la place de lutilisateur ni essayer dimaginer sonbesoin. Lissue fatale serait alors de raliser un code ne satisfaisant pas lutilisateur.

Sassurer davoir ralis un code facilement modifiable, permettant de prendre encompte des volutions futures.

Dfinir larchitecture de lapplication (dfinition de ses diffrents composants, ind-pendamment du langage de programmation) afin de bien comprendre les relationsentre les composants de lapplication.

Raliser une batterie de tests afin de mesurer, dune certaine manire, la qualit ducode.

Effectuer un suivi des besoins de lutilisateur afin dintgrer des amliorations.

Effectuer des corrections de bogues. La prsence de bogues tant invitable, il faut lagrer plutt que la subir.

crire la documentation utilisateur. crire la documentation dinstallation de lapplication. crire la documentation de lapplication afin quune autre quipe de dveloppeurs

puisse reprendre le dveloppement.

Effectuer des tests de monte en charge afin de mesurer les capacits de rsistance et laperformance de lapplication.

Effectuer une sparation des tches de dveloppement afin de raccourcir les dlais delivraison de lapplication.

Ces activits visent mieux structurer lensemble des tches effectuer lors de la cons-truction dune application. Notons, de plus, que certaines activits dpendent dautres etquil faut parfois imprativement effectuer une activit avant den dmarrer une autre.

La figure 1.2 prsente une vision de lensemble de ces activits et de leur entrelacement(chaque flche prcise une dpendance dans la ralisation des activits). Cette figure faitbien ressortir la complexit intrinsque de la construction dune application. Nousvoyons clairement quil y a beaucoup dactivits raliser et que lordre de ralisation deces activits nest pas trivial.

Un curieux besoin de modles CHAPITRE 1 3

Pour faire face cette complexit de construction des applications informatiques, ling-nierie logicielle propose depuis plusieurs annes des mthodes et des techniques permet-tant de rpondre aux questions suivantes :

Quand raliser une activit ? Qui doit raliser une activit ? Quoi faire dans une activit ? Comment raliser une activit ?

Figure 1.2Vision dune partie des activits raliser pour construire une application

Besoin

Solution

Analyse

Architecture

Ralisation

Tests

Sparation dudveloppement

Intgration

Impact

Maintenance

Mise en production

Mise en prproduction

Test de monteen charge

Evolution

Rutilisation


Ces questions synthtisent grosso modo le problme de la construction dapplicationsinformatiques. Les deux premires visent identifier et organiser les diffrentes activitsncessaires la construction dune application informatique. Les deux dernires visent bien dfinir les travaux devant tre raliss dans chacune des activits.Ltendue de la tche et lvolution constante des technologies nous font mieuxcomprendre pourquoi lingnierie logicielle est un domaine ouvert, dans lequel nombrede problmes restent encore rsoudre.Dans le cadre de ce cours, nous nous focalisons uniquement sur les activits relatives aucode (gnration, analyse, documentation, tests, etc.). De plus, nous ne traitons quasi-ment pas les deux questions relatives lorganisation des activits (quand et qui). Notreobjectif est de montrer en quoi les diffrentes techniques de modlisation UML (quoi etcomment) permettent dobtenir rapidement un gain de productivit.

Le codeNous avons introduit la section prcdente un ensemble non exhaustif dactivits quilest ncessaire de raliser pour construire une application informatique. Dans cet ensem-ble, la ralisation du code napparat que comme une activit parmi dautres.Cependant, comme nous lavons indiqu, la ralisation du code reste la finalit. Toutesles autres activits visent soit faciliter cette ralisation, soit loptimiser, soit permet-tre son volution.Le code occupe donc une place particulire dans la construction dune application infor-matique, mais laquelle exactement ?Une premire certitude est que, pour excuter une application, il faut la coder. Le code estdonc absolument ncessaire lexcution des applications. Peut-on dire pour autant quele code soit lapplication ? En dautres termes, peut-on considrer que le code, lui seul,reprsente lintgralit de lapplication ?Les questions suivantes permettent de mieux cerner la place du code dans une applicationinformatique :1. Question. Comment le code peut-il tre utilis pour faciliter la maintenance des

applications informatiques ?Rponse. Nous pourrions penser commenter le code afin de faciliter la mainte-nance, mais il faudrait alors dfinir le niveau de dtail adquat. La charte Linuxpropose, par exemple, de ne pas surdocumenter le code, car celui-ci devient viteillisible. Dans le projet Linux, les commentaires sont utiliss pour spcifier destravaux faire ou des points dlicats mais ne sont pas destins la maintenance.Nous pouvons donc considrer que le code ne peut pas rellement tre utilis pourfaciliter la maintenance.

2. Question. Comment pouvons-nous retrouver les fonctionnalits dune application enlisant le code ?


Rponse. Cest un travail difficile, qui ne peut tre automatis. Il est ncessaire deconstituer une documentation diffrente du code pour expliquer dautres personnesles fonctionnalits de lapplication.

3. Question. Comment pouvons-nous dcrire la faon de mettre en production uneapplication ?Rponse. Le code ne sert rien pour cela. Il est ncessaire de fournir une documenta-tion dinstallation.

4. Question. Comment pouvons-nous dcrire la faon dutiliser une application ?Rponse. Le code ne sert rien l non plus. Il est ncessaire de fournir une documen-tation dutilisation.

Ces quelques questions-rponses permettent de comprendre, dune part, que le codeoccupe une place indispensable dans la construction dune application et, dautre part,quil ne permet pas, lui seul, de reprsenter toute lapplication. Il est ncessaire davoirdautres ressources (guide, documentation, etc.) pour supporter certaines activits dedveloppement (maintenance, installation, etc.).Pour illustrer cette diffrence entre code et application informatique, nous considreronsdans la suite du cours que la construction dune application consiste raliser une solu-tion au problme dun utilisateur (voir figure 1.3). Le code est la matrialisation de cettesolution. En dautres termes, le code seul ne suffit pas.

Nous considrons que, quel que soit le langage de programmation, le code a pour uniqueobjectif dtre compil et excut. Toutes les autres informations utiles au dveloppe-ment dune application nont pas rellement leur place dans le code.

Figure 1.3Deuxime simplification de la ralisation dune application

Besoin

Solution

Avoir un logiciel pourcrire un livre ou une

lettre

Word

Code Code source de Word


DocumentationCe constat de diffrence entre code et application informatique nest pas nouveau. Onsaccorde dailleurs aujourdhui sur un ensemble de documents ncessaires raliserpour complter le code.Le tableau 1.1 recense un sous-ensemble des documents raliser lors de la constructiondune application. Ces documents sont changs entre les clients de lapplication et lesdiffrents membres de lquipe de dveloppement. Nous identifions parmi ces dernierslarchitecte, dont le rle est de concevoir les composants principaux de lapplication, ledveloppeur, dont le rle est de dvelopper les composants de lapplication, et ladministra-teur, dont le rle est dinstaller lapplication afin quelle puisse tre utilise par lutilisateur.Insistons nouveau sur le fait que ces documents ne peuvent tre directement intgrs aucode, que ce soit sous forme de commentaire ou autre.

Cette liste donne la mesure de ltendue du problme de la documentation des applica-tions. Il faut non seulement rdiger normment de documentations, mais surtout faireattention ce que ces documentations soient comprhensibles (afin que rdacteurs etlecteurs se comprennent) et quelles soient cohrentes entre elles.

Tableau 1.1 Liste non exhaustive des documents ncessaires la ralisation dune application

Document FonctionDocumentation utilisateur Prcise la faon dont on peut utiliser lapplication. Un tel document peut aussi

contenir une section dcrivant la faon dinstaller lapplication. Ce document est rdig par lquipe de dveloppement et est destin aux utilisateurs de lapplica-tion.

Documentation des services offerts par lapplication

Prsente une vision macroscopique de lapplication et liste les fonctionnalits ralises par lapplication. Ce document est rdig par lquipe de dveloppe-ment et est destin aux utilisateurs de lapplication.

Documentation darchitecture de lapplication

Prcise la faon dont lapplication est structure en terme de gros composants. Ce document est rdig par les architectes et est destin tous les membres de lquipe de dveloppement.

Documentation des logiciels ncessaires lutilisation de lapplication

Dresse la liste des logiciels ncessaires linstallation et lexcution de lappli-cation. Ce document est rdig par lquipe de dveloppement et est destin aux administrateurs, afin quils puissent mettre lapplication en production.

Documentation des tests effectus

Liste lensemble des tests qui ont t effectus sur lapplication. On peut de la sorte tester nouveau lapplication aprs lavoir modifie et vrifier ainsi quelle ne gnre pas derreurs sur certains scnarios dutilisation (scnarios couverts par les tests). Ce document est rdig par lquipe de dveloppement et est des-tin aux dveloppeurs futurs.

Documentation de la concep-tion de lapplication

Prcise la conception de lapplication (en terme de classes, par exemple). Ce document est rdig par lquipe de dveloppement et est destin aux dve-loppeurs.

Spcification des besoins Prcise les besoins exprims par le futur utilisateur de lapplication, aussi appel client. Ce document est rdig par le client et est destin lquipe de dvelop-pement.


Ce problme peut tre rsum de la faon suivante : Comment rdiger les documentations afin quelles soient intelligibles de manire non

ambigu (en anglais ? en franais ? faut-il dfinir un dictionnaire commun ?) ? Comment sassurer que les documentations ne contiennent pas dincohrences ?Cest pour rpondre ces questions que les modles sont de plus en plus utiliss lors dela construction des applications.

Les modlesAvant de prciser en quoi les modles sont intressants pour la construction dapplica-tions informatiques, il est intressant de prciser la dfinition du terme modle.Le dictionnaire de la langue franaise en ligne TLFI (Trsor de la langue franaise infor-matis) donne les dfinitions suivantes du mot modle (http://atilf.atilf.fr/tlf.htm) : Arts et mtiers : reprsentation petite chelle dun objet destin tre reproduit dans

des dimensions normales. pistmologie : systme physique, mathmatique ou logique reprsentant les struc-

tures essentielles dune ralit et capable son niveau den expliquer ou den repro-duire dynamiquement le fonctionnement.

Cyberntique : systme artificiel dont certaines proprits prsentent des analogiesavec des proprits, observes ou infres, dun systme tudi et dont le comporte-ment est appel, soit rvler des comportements de loriginal susceptibles de fairelobjet de nouvelles investigations, soit tester dans quelle mesure les proprits attri-bues loriginal peuvent rendre compte de son comportement manifeste.

Dans un contexte informatique, nous proposons la dfinition suivante, qui synthtise lestrois dfinitions nonces prcdemment :

Un modle contient donc plusieurs informations sur une application informatique. Cesinformations ont toutes vocation faciliter dune manire ou dune autre la production ducode de lapplication. Un modle peut, entre autres choses, prciser les diffrentesdonnes manipules par lapplication (vue des donnes), prciser les diffrentes fonc-tionnalits directement offertes aux utilisateurs de lapplication (vue des utilisateurs) etprciser les technologies, telles que Java, utilises pour raliser lapplication (vue techni-que).En dautres termes, un modle est compos de plusieurs vues sur une application.Chacune de ces vues contient certaines informations sur lapplication. Ces vues peuventcibler diffrents niveaux dabstraction, et elles doivent tre cohrentes.

Modle (informatique et construction dapplications) : les modles dapplications informatiques sont desreprsentations, diffrents niveaux dabstraction et selon plusieurs vues, de linformation ncessaire laproduction et lvolution des applications.


La figure 1.4 schmatise un modle dapplication compos de trois vues.

Les modles intgrent donc diffrentes vues, diffrents niveaux dabstraction dunemme application informatique. Lensemble des vues doit tre cohrent ; deux vues nedoivent donc pas spcifier dinformation incohrente.Les modles permettent ainsi dharmoniser lensemble des documentations des applica-tions informatiques en un unique ensemble cohrent.Pour pouvoir utiliser des modles, il faut dfinir un langage de modlisation partag partous. Nous traitons dans le cadre de ce cours du langage UML, qui est le langage demodlisation dapplications informatiques le plus largement partag aujourdhui.

Modles et codeNous venons de voir que les modles contenaient, selon diffrentes vues et diffrentsniveaux dabstraction, linformation ncessaire la production et lvolution des appli-cations informatiques.

Rappelons que le code est diffrent du modle. Il est, comme nous lavons dj indiqu,la matrialisation de la solution.

Figure 1.4 Modle dune application

Vue des donnes

Vue technique

Vue des utilisateurs

Application


Cependant, il est important dajouter les prcisions suivantes : Le code nest pas plus dtaill que les modles. En effet, le modle devant contenir

toute linformation permettant la production du code, un modle doit tre au moinsaussi dtaill que le code.

Faire un modle nest pas plus facile qucrire du code. En effet, le modle contientbeaucoup plus dinformation que le code. De plus, ces informations fortement diversi-fies se doivent dtre cohrentes. Llaboration dun modle complet est donc unexercice encore plus difficile que la rdaction de code.

Ne pas confondre niveau dabstraction et niveau de prcision. Nous entendons parabstraction le fait de pouvoir masquer dans une vue certaines informations inutiles parrapport lobjectif bien dfini de cette vue. Par exemple, il nest pas intressant demontrer les dtails techniques Java dans la vue des donnes. Pour autant, toutes lesinformations de chaque vue doivent tre prcises.

Les modles doivent tre productifs plutt que dclaratifs. Lobjectif des modles estde contenir linformation ncessaire la production et lvolution du code. Les infor-mations contenues dans les modles doivent donc tre synchronises avec le code.Cest la raison pour laquelle nous considrons les modles comme des lments deproduction plutt que comme des lments de documentation.

Figure 1.5 Concept de modle UML dune application informatique, avec les vues, les niveaux dabstraction, les relations de cohrence et la relation avec le code

Structure Comportement Fonctionnalit

CODE

VUES

AB

ST

RA

CT

ION COHERENCE


Notre cours se concentre sur le langage de modlisation UML. Plus prcisment, parmiles vues proposes par ce langage, nous nous attacherons prsenter les vues structurelle , comportementale et fonctionnelle .Nous prsenterons chacune de ces vues selon trois niveaux dabstraction et expliqueronsles relations de cohrence qui existent entre chacune de ces vues chaque niveaudabstraction. Nous prciserons de plus la relation de synchronisation qui existe entre lemodle UML et le code.La figure 1.5 synthtise le concept de modle tel que nous le prsentons dans ce cours,avec ses diffrentes vues, ses diffrents niveaux dabstraction, ses relations de cohrenceet sa relation avec le code.Nous considrons quun modle est compos de neuf parties, une partie chaque inter-section dune vue et dun niveau dabstraction.Nous nous attacherons tout au long de ce cours prciser comment utiliser UML seloncette reprsentation.

SynthseDans ce premier chapitre, nous avons pass en revue toutes les activits ncessaires la construction dapplications informatiques et ainsi soulign la complexitintrinsque de cette tche. Rappelons que ces activits permettent uniquement de grercette complexit, et non de la simplifier.Nous avons ensuite prsent la place du code dans une application informatique, eninsistant sur le fait que le code ntait que la matrialisation dune applicationinformatique. Nous avons dtaill une partie des documents ncessaires laralisation des applications. La dfinition de lensemble de ces documents permetessentiellement de rpondre aux questions du comment et quoi laborer.Nous avons galement introduit le concept de modle. Les modles dapplicationsinformatiques sont des reprsentations, diffrents niveaux dabstraction, delinformation ncessaire la production et lvolution des applications. Un modlecontient donc un ensemble dinformations cohrentes sur une applicationinformatique.Pour finir, nous avons prcis le concept de modle tel quil sera tudi dans le cadrede ce cours, cest--dire selon les vues structurelle , comportementale et fonctionnelle , sur trois niveaux dabstraction. Nous prsenterons de plus lesrelations de cohrence entre ces lments de modles ainsi que la relation desynchronisation avec le code.


Tr a v a u x d i r i g s

TD1. Un curieux besoin de modles partir du code donn en annexe de louvrage, rpondez aux questions suivantes.Question 1. En une phrase, quels sont les rles de chacune des classes ?Question 2. Peut-on dire quil existe des classes reprsentant des donnes et des

classes reprsentant des interfaces graphiques ? Si oui, pourquoi etquelles sont ces classes ?

Question 3 Est-il possible que le numro de tlphone dune personne soit+33 1 44 27 00 00 ?

Question 4 Est-il possible que ladresse e-mail dune personne soit je_ne_veux_pas_donner_mon_email ?

Question 5 Quelles sont les fonctionnalits proposes par les menus graphiques decette application ?

Question 6 Quelles sont les fonctionnalits rellement ralises par cetteapplication ?

Question 7 Est-il possible de sauvegarder un rpertoire dans un fichier ?Question 8 Si vous aviez rdiger un document dcrivant tout ce que vous savez sur

cette application afin quil puisse tre lu par un dveloppeur qui veut ruti-liser cette application et un chef de projet qui souhaite savoir sil peut int-grer cette application, quelles devraient tre les caractristiques de votredocument ?

Question 9 Rdigez un document prsentant lapplication MyAssistant.Question 10 Rdigez un document dcrivant les fonctionnalits de lapplication

MyAssistant.

Question 11 Rdigez un document dcrivant larchitecture gnrale de lapplicationMyAssistant.

Ce TD aura atteint son objectif pdagogique si et seulement si : Vous avez conscience que le code seul ne suffit pas pour dcrire une application. Vous avez conscience que la construction de documentations est un travail labo-

rieux et dlicat. Vous commencez comprendre lintrt de la modlisation.

2Diagrammes de classes

Vue structurelle du modle UMLLa vue structurelle du modle UML est la vue la plus utilise pour spcifier une applica-tion. Lobjectif de cette vue est de modliser la structure des diffrentes classes duneapplication oriente objet ainsi que leurs relations.

Paradigme orient objetConu lorigine, au cours des annes 1990, pour faciliter la construction dapplicationsorientes objet (OO), le langage UML a ensuite fortement volu jusqu sa version 2.1actuelle. Nanmoins, UML reste toujours trs OO. Les concepts quil propose pourmodliser la vue structurelle sont donc les concepts de classe et dobjet.UML dfinit cependant sa propre smantique OO, laquelle ressemble la smantique deslangages de programmation objet Java ou C++. Il est donc important de considrer UMLcomme un langage part entire, et non comme une couche graphique permettant dedessiner des applications Java ou C++.

Objectifs Prsenter les concepts UML relatifs la vue structurelle (diagramme de classes) Prsenter la notation graphique du diagramme de classes UML Expliquer la smantique des classes UML (compatible avec la smantique des

langages de programmation orients objet)

UML pour les dvelopperus14

Lobjectif de lensemble de ce cours tant de prsenter UML pour le dveloppeur, unminimum de connaissances du paradigme orient objet est requis. Les concepts lmen-taires suivants du paradigme objet seront donc supposs connus : objet classe instance hritage polymorphisme encapsulation

Concepts lmentairesLes concepts lmentaires que nous prsentons dans cette section sont les plus employspour la ralisation de la vue structurelle dun modle UML.

Classe

SmantiqueEn UML, une classe dfinit la structure commune dun ensemble dobjets et permet laconstruction dobjets instances de cette classe. Une classe est identifie par son nom.GraphiqueUne classe se reprsente laide dun rectangle, qui contient le nom de la classe. Lafigure 2.1 illustre la classe nomme Personne.

Interface

SmantiqueEn UML, une interface dfinit un contrat que doivent respecter les classes qui ralisentlinterface. Une interface est identifie par son nom. Les objets instances des classes quiralisent des interfaces sont aussi des instances des interfaces. Une classe peut raliserplusieurs interfaces, et une interface peut tre ralise par plusieurs classes.

GraphiqueUne interface se reprsente de deux faons : soit laide dun rectangle contenant le nomde linterface, au-dessus duquel se trouve la chane de caractres interface, soit laide dun cercle, au-dessous duquel se trouve le nom de linterface (voir figure 2.2).

Figure 2.1 Reprsentation graphique dune classe

Personne

Diagrammes de classes CHAPITRE 2 15

La relation de ralisation entre une classe et une interface est reprsente par une flchepointille la tte en forme de triangle blanc.La figure 2.3 reprsente la classe Personne qui ralise linterface IPersonne.

Proprit (anciennement appele attribut) dune classe ou dune interfaceSmantiqueLes classes et les interfaces peuvent possder plusieurs proprits. Une proprit a unnom et un type. Le type peut tre soit une classe UML, soit un type de base (integer,string, boolean, char, real). Un objet instance de la classe ou de linterface doit porter lesvaleurs des proprits de sa classe.

GraphiqueLes proprits dune classe ou dune interface se reprsentent dans le rectangle reprsen-tant la classe ou linterface. Chaque proprit est reprsente par son nom et son type.La figure 2.4 prsente la classe Personne, avec sa proprit nom de type string.

Opration dune classe ou dune interface

SmantiqueLes classes et les interfaces peuvent possder plusieurs oprations. Une opration a unnom et des paramtres et peut lever des exceptions. Les paramtres sont typs et ont unsens (in, out, inout, return).

Figure 2.2 Reprsentations graphiques dune interface

interfaceIPersonne

IPersonne

Figure 2.3 Reprsentation graphique dune relation de ralisation

interfaceIPersonne

Personne

Figure 2.4 Reprsentation graphique dune proprit dune classe

Personne

nom : string


Un objet instance de la classe ou de linterface est responsable de la ralisation des opra-tions dfinies dans la classe ou dans linterface.Si le sens dun paramtre de lopration est in, lobjet appelant lopration doit fournir lavaleur du paramtre. Si le sens dun paramtre de lopration est out, lobjet responsablede lopration doit fournir la valeur du paramtre. Si le sens dun paramtre de lopra-tion est inout, lobjet appelant lopration doit fournir la valeur du paramtre, mais celle-ci peut tre modifie par lobjet responsable de lopration.Un seul paramtre peut avoir return comme sens, et il nest alors pas ncessaire de prci-ser le nom de ce paramtre. Si une opration possde un paramtre dont le sens estreturn, cela signifie que lobjet responsable de lopration rend cette valeur comme rsul-tat de lopration. Lapport de la direction return par rapport la direction out est de faci-liter la combinaison de fonction.Pour finir, les exceptions dune opration sont types.Il est important de souligner que les oprations UML ne dfinissent pas le comportementqui sera ralis lors de linvocation de lopration. Nous verrons dans la suite du courscomment ce comportement est intgr dans le modle.

Graphique

Les oprations dune classe ou dune interface se reprsentent dans le rectangle reprsen-tant la classe ou linterface. Chaque opration est reprsente par son nom et ses param-tres. Il est aussi possible de masquer les paramtres de lopration.

La figure 2.5 prsente la classe Personne avec son opration getNom.

Hritage entre classes

Smantique

En UML, une classe peut hriter dautres classes. Lhritage entre classes UML doit treconsidr comme une inclusion entre les ensembles des objets instances des classes. Lesobjets instances des sous-classes sont des objets instances des superclasses. En dautrestermes, si une classe A hrite dune classe B, lensemble des objets instances de A estinclus dans lensemble des objets instances de B.Ce faisant, tout objet instance de A doit possder les valeurs des proprits dfinies dansA et dans B et doit tre responsable des oprations dfinies dans A et dans B.

Nous verrons dans la suite de ce cours que la relation dhritage entre deux classes appar-tenant des packages diffrents dpend de certaines rgles.

Figure 2.5 Reprsentation graphique dune opration dune classe getNom()

Personne

nom : string


GraphiqueLa relation dhritage entre deux classes est reprsente par une flche la tte en formede triangle blanc.La figure 2.6 reprsente la classe Personne, qui hrite de la classe EtreVivant.

Package

SmantiqueUn package permet de regrouper des classes, des interfaces et des packages. Classes,interfaces et packages ne peuvent avoir quun seul package dans lequel ils sont regrou-ps. La possibilit dtablir un lien entre des classes et des interfaces dpend du lien quiexiste entre les packages qui les contiennent.Nous dtaillons ces concepts avancs la section suivante.

GraphiqueLes packages se reprsentent laide dun rectangle possdant un onglet dans lequel estinscrit le nom du package. Les lments contenus se reprsentent dans le rectangle. Lataille du rectangle sadapte la taille de son contenu.La figure 2.7 reprsente le package nomm personnel, qui contient la classe Personne.

Figure 2.6 Reprsentation graphique de la relation dhritage entre classes

EtreVivant

Personne

Figure 2.7 Reprsentation graphique dun package interface

IPersonne

Personne

personnel


Import de package

SmantiqueAfin que les classes dun package puissent hriter des classes dun autre package ou ytre associes (voir section suivante), il faut prciser une relation dimport entre ces deuxpackages. La relation dimport est monodirectionnelle, cest--dire quelle comporte unpackage source et un package cible. Les classes du package source peuvent avoir accsaux classes du package cible.Nous revenons sur cette smantique au chapitre 4 de ce cours, mais nous pouvons djmentionner que nous considrons comme interdits les cycles de relations dimport entreplusieurs packages.

GraphiqueLa relation dimport entre deux packages sexprime laide dune flche en pointill. Lachane de caractres access element inscrite au-dessus de cette flche peut tre optionnel-lement positionne.La figure 2.8 prsente la relation dimport entre deux packages P1 et P2 contenantrespectivement les classes A et B. Nous considrons ici que la classe A a besoin dacc-der la classe B.

Note

SmantiqueUne note UML est un paragraphe de texte qui peut tre attach nimporte quel lmentdu modle UML (package, classe, proprit, opration, association). Le texte contenudans la note permet de commenter llment cibl par la note.

GraphiqueLes notes se reprsentent laide dun rectangle contenant le texte et dont un des coins estcorn. Une ligne discontinue permet de relier la note llment du modle quelle cible.La figure 2.9 reprsente une note attache lopration nomme getNom().

Figure 2.8 Reprsentation graphique de la relation dimport entre deux packages A

p1

B

p2

Figure 2.9 Reprsentation graphique dune note associe une opration

Cette opration permetd'obtenir le nom de la personne (proprit nom)

getNom()

Personne

nom : string


Associations entre classesLe langage UML dfinit le concept dassociation entre deux classes. Ce concept trs int-ressant, qui ne fait pas partie des concepts lmentaires du paradigme objet, permet deprciser les relations qui peuvent exister entre plusieurs objets.En UML, une association se fait entre deux classes. Elle a un nom et deux extrmits, quipermettent de la connecter chacune des classes associes. Lorsquune association estdfinie entre deux classes, cela signifie que les objets instances de ces deux classespeuvent tre relis entre eux.La figure 2.10 prsente lassociation nomme habite, qui associe les classes Personne etAdresse. Cette association signifie que les objets instances de la classe Personne et lesobjets instances de la classe Adresse peuvent tre relis. En dautres termes, cela signifieque des personnes habitent des adresses.

Chaque extrmit de lassociation a un nom de rle, qui permet didentifier chacune desclasses lies dans le contexte de lassociation.La figure 2.11 reprsente la mme association en prcisant le nom des rles de chaqueclasse lie. Dans le contexte de cette association, la classe Personne reprsente lhabitantalors que la classe Adresse reprsente la rsidence. En dautres termes, cette associationsignifie que les personnes habitent des adresses et quils sont les habitants de ces rsi-dences.

En UML, il est possible de spcifier chaque extrmit les nombres minimal et maximaldobjets devant tre relis.La figure 2.12 reprsente la mme association en prcisant les nombres minimal et maxi-mal dobjets devant tre relis. La lecture de ce diagramme est la suivante : rsidence 1 : pour 1 habitant, il y a au minimum 1 rsidence et au maximum

1 rsidence.

Figure 2.10 Reprsentation graphique dune association nomme

getNom()

nom : stringtel[1..4]:stringprenom[1..*]:string

Personne

Adressehabite

Figure 2.11 Reprsentation graphique dune association et de ses rles

getNom()

Personne


Adresse

habitant

*

rsidence

1

habite


habitant * : pour 1 rsidence, il y a au minimum 0 habitant et au maximum une infinitdhabitants.

En UML, il est possible de rendre chacune des extrmits navigable ou non. Si une extr-mit est navigable, cela signifie que lobjet peut naviguer vers lautre objet auquel il estreli et ainsi obtenir les valeurs de ses proprits ou invoquer les oprations dont il estresponsable. la figure 2.12, les habitants peuvent naviguer vers leurs rsidences (et pas linverse), cequi permet dobtenir, par exemple, le numro de rue.

Pour finir, il est possible en UML de prciser des smantiques de contenance sur les asso-ciations. Par exemple, il est possible de prciser sur une extrmit quune classe associejoue un rle de conteneur, lautre classe jouant le rle de contenu.UML propose deux smantiques de contenance : une smantique de contenance faible,dite dagrgation, qui permet de prciser que les lments contenus peuvent tre partagsentre plusieurs conteneurs, et une smantique de contenance forte, dite composition, quipermet de prciser que les lments contenus ne peuvent tre partags entre plusieursconteneurs.

Du point de vue graphique, la relation de contenance se reprsente laide dun losangesur lextrmit. Le losange est blanc pour lagrgation et noir pour la composition.La figure 2.13 prcise que la classe Personne joue un rle de conteneur pour la classeCompteBancaire dans le cadre de lassociation moyens de paiement, ce qui signifie quuncompte bancaire ne peut tre le moyen de paiement que dune seule personne.

Figure 2.12 Reprsentation graphique dune association navigable

getNom()

Personne


Adresse

habitant

*

rsidence

1

habite

Figure 2.13 Reprsentation graphique dune association de composition

getNom()

Personne


CompteBancaire

titulaire

1

compteCourant

*

moyens de paiement


Concepts avancsLes concepts lmentaires que nous venons de prsenter sont largement utiliss pour modliserla vue comportementale dune application. Les concepts avancs que nous prsentons le sontmoins mais permettent cependant de faciliter la ralisation des oprations de Reverse Enginee-ring et de gnration de code que nous prsenterons dans les chapitres suivants de ce cours.

Classe abstraite

SmantiqueUne classe UML peut tre abstraite. Dans ce cas, elle ne peut pas directement instancierun objet.Dans une classe abstraite, il est possible de prciser que certaines proprits et certainesoprations sont abstraites. Ce sont prcisment les valeurs de ces proprits et les respon-sabilits de ces oprations que les objets ne peuvent pas supporter directement. Cest laraison pour laquelle aucun objet ne peut tre directement instance dune classe abstraite.Pour que des objets soient instances dune classe abstraite, il faut obligatoirement quilssoient instances dune classe non abstraite, laquelle hrite de la classe abstraite et rendnon abstraites les proprits et les oprations abstraites.

GraphiqueEn UML 2.0, il nexiste pas de reprsentation graphique particulire pour les classesabstraites. En UML 1.4, il fallait mettre le nom de la classe en italique.

Multiplicit des proprits et des paramtres

SmantiqueIl est possible de prciser quune proprit ou un paramtre peut porter plusieurs valeurs.UML permet de prciser les nombres minimal et maximal de ces valeurs. Prciser quuneproprit peut avoir au minimum une valeur et au maximum une infinit de valeursrevient prciser que la proprit est un tableau infini.

GraphiquePour les proprits et les paramtres, les nombres minimal et maximal des valeurs appa-raissent entre crochets. Le caractre * est utilis pour prciser que le nombre maximal devaleurs est infini.La figure 2.14 prsente diffrentes proprits en prcisant des nombres minimal et maxi-mal de valeurs.

Figure 2.14 Reprsentation graphique des multiplicits des proprits

getNom()

Personne



Visibilit des classes, des proprits et des oprations

Smantique

Il est possible de prciser la visibilit des proprits et des oprations des classes. Lesvisibilits portent sur les accs aux proprits et aux oprations. On dit quune classe Aaccde la proprit dune classe B si le traitement associ une opration de A utilisela proprit de B. On dit quune classe A accde lopration dune classe B si le traite-ment associ une opration de A fait un appel lopration de B.

Les visibilits proposes par UML 2.0 sont les suivantes :

public : la proprit ou lopration peuvent tre accdes par nimporte quelle autreclasse.

private : la proprit ou lopration ne peuvent tre accdes que par la classe elle-mme.

protected : la proprit ou lopration ne peuvent tre accdes que par des classes quihritent directement ou indirectement de la classe qui dfinit la proprit ou lopra-tion.

Graphique

Dans la reprsentation graphique de llment, les visibilits sont reprsentes de lafaon suivante :

Le caractre + est utilis pour prciser la visibilit public.

Le caractre - est utilis pour prciser la visibilit protected.

Le caractre # est utilis pour prciser la visibilit private.

Proprits et oprations de classe

Smantique

Il est possible de prciser que la valeur dune proprit dfinie par une classe est portedirectement par la classe elle-mme (et non par chacun des objets). De mme, il estpossible de prciser quune classe est directement responsable dune opration quelledfinit. On appelle ces proprits et ces oprations des lments de niveau classe .

Graphique

Dans la reprsentation graphique de la classe, les proprits et les oprations de niveauclasse sont soulignes.



TD2. Diagrammes de classesQuestion 12 Dfinissez la classe UML reprsentant un tudiant, caractris, entre

autres, par un identifiant, un nom, un prnom et une date de naissance.Question 13 Dfinissez la classe UML reprsentant un enseignant, caractris, entre

autres, par un identifiant, un nom, un prnom et une date de naissance.Question 14 Dfinissez la classe UML reprsentant un cours, caractris par un identi-

fiant, un nom, le nombre dheures de cours magistral, le nombre dheuresde travaux dirigs et un nombre dheures de travaux pratiques que doitsuivre un tudiant.

Question 15 Dfinissez les associations qui peuvent exister entre un enseignant et uncours.

Question 16 Dfinissez la classe UML reprsentant un groupe dtudiants en utilisantles associations.

Question 17 Dfinissez lassociation possible entre un groupe dtudiants et un cours.Question 18 Pensez-vous quil soit possible de dfinir un lien dhritage entre les classes

UML reprsentant respectivement les tudiants et les enseignants ?Question 19 Pensez-vous quil soit possible de dfinir un lien dhritage entre les classes

UML reprsentant respectivement les tudiants et les groupes dtudiants ?

SynthseDans ce deuxime chapitre, nous avons prsent le diagramme de classes UML quipermet de reprsenter la vue structurelle des applications informatiques. Ce chapitrene se veut pas un guide de rfrence du diagramme de classes. Nous avons simplementprsent les concepts relatifs ce diagramme dont nous aurons besoin dans la suite ducours.

En introduisant ces concepts, nous avons dtaill aussi bien leur smantique propreque la faon de la reprsenter graphiquement. Rappelons que la smantique de cesconcepts est proche de celle des langages de programmation orients objet sans luitre quivalente.Pour finir, soulignons le fait que les diagrammes de classes UML peuvent treemploys tout niveau dabstraction. Rien nempche de reprsenter une applicationinformatique laide dune seule classe (haut niveau dabstraction) ou de reprsentertous les composants de cette application comme des classes (bas niveau dabstraction).


Question 20 On nomme coursDeLEtudiant() lopration permettant dobtenir lensembledes cours suivis par un tudiant. Positionnez cette opration dans uneclasse, puis prcisez les paramtres de cette opration, ainsi que lesmodifications apporter aux associations pralablement identifies pourque votre solution soit ralisable.

Question 21 On nomme coursDeLEnseignant() lopration permettant dobtenirlensemble des cours dans lesquels intervient un enseignant. Positionnezcette opration dans une classe, puis prcisez les paramtres de cetteopration, ainsi que les modifications apporter aux associations prala-blement identifies pour que votre solution soit ralisable.

Question 22 Expliquez le diagramme de classes reprsent la figure 2.15.

Question 23 Positionnez toutes vos classes (Etudiant, Enseignant, Cours,GroupeEtudiant) dans un package nomm Personnel.

Question 24 Liez vos classes pour faire en sorte quun crneau soit li un cours !

Figure 2.15 Package planning

Planning

numro:integer

Salle

calculerCreneauxLibres()

numro:integer

Semaine

ferie()calculerCreneauxLibres()

date:stringnom:string

Jours

heureDebut:stringheureFin:string

Creneau

salle* salle

1

occupe

*

joursOuvrables5

jours1

crneaux*

planning


Ce TD aura atteint son objectif pdagogique si et seulement si : Vous matrisez la notion de classe. Vous matrisez la signification des associations et hritages entre classes. Vous avez compris la rpercussion des associations entre classes sur les dpen-

dances entre packages.

3Reverse Engineering

Smantiques UML et JavaComme indiqu au chapitre prcdent, le langage UML est conu pour faciliter la cons-truction dapplications orientes objet. La premire version de ce langage, qui a t dfi-nie en 1995, a t trs fortement influence par les concepts des langages de programma-tion oriente objet de lpoque, tels que C++, Smalltalk, etc.Les concepts UML de la partie relative au diagramme de classes, que nous avons prsen-ts au chapitre prcdent, sont donc des concepts orients objet. En particulier, lesconcepts de classe, de proprit, dopration et de package sont partags par tous leslangages de programmation oriente objet.Afin de bien souligner ladquation du langage UML au paradigme objet, il est intres-sant de rappeler que la premire lettre de lacronyme UML renvoie Unified. Ce motprcise que le langage UML incarne lunification de quasiment tous les langages demodlisation dapplications orientes objet.

Objectifs Prciser les diffrences smantiques entre modle UML (partie diagramme de

classes) et code (Java)

Prsenter lopration de Reverse Engineering et en identifier les gains et les limites Prsenter la diffrence entre modle UML et diagramme UML


Diffrences des smantiquesSi UML partage une smantique commune avec les langages de programmation orienteobjet, cela ne veut pas dire quil ait exactement la mme smantique que ces langages.Comme chaque langage de programmation oriente objet, UML possde sa propresmantique, laquelle prsente des diffrences significatives avec les smantiques deslangages de programmation. Nous dtaillons dans cette section une partie des diffrencesentre la smantique UML et la smantique Java. Notre objectif est de montrer que leslangages UML et Java ont chacun leur propre smantique.

Concepts UML inexistants dans les langages de programmation

Association

En Java, pour que des objets instances dune classe A rfrencent des objets instancesdune classe B, il faut dfinir un attribut de type B dans la classe A. Il est de plus possibledutiliser les tableaux Java afin quun objet instance dune classe A rfrence plusieursobjets instances dune classe B.De manire similaire, UML permet de dfinir une proprit de type B dans une classe A. Il estaussi possible dutiliser les multiplicits de cette proprit pour rfrencer plusieurs objets.Pour autant, le concept UML dassociation, que nous avons prsent au chapitre prc-dent, nexiste pas en Java, qui ne permet que de dfinir des rfrences entre les classes, cequi est diffrent des associations. En particulier, en Java, il nest pas possible de prciserque deux rfrences appartenant deux classes correspondent la mme association etque lune est loppose de lautre.

Import entre packages

En Java, la notion de package nexiste qu travers la notion de classe. Il nest donc paspossible de dfinir de package sans avoir au pralable dfini une classe. Il nest pas nonplus possible de dfinir des rgles dimport entre packages, car, en Java, la relationdimport est toujours dfinie entre une classe et un ensemble de classes qui peut treidentifi par un nom de package.En UML, la notion de package existe indpendamment de la notion de classe. Il est deplus possible, comme nous lavons montr au chapitre prcdent, de dfinir des relationsdimport directement entre les packages.

Direction des paramtres

En Java, les valeurs des paramtres dune opration sont toujours donnes par lappelantde lopration. Lappel ne peut transmettre que la valeur de retour de lopration. Deplus, si un objet est transmis comme valeur de paramtre par lappelant, lappel peutchanger les valeurs des attributs de lobjet, mais non lobjet en lui-mme (il nest paspossible de remplacer lobjet par un autre objet).

Reverse Engineering CHAPITRE 3 29

En UML, les paramtres dune opration ont une direction (in, out, inout, return), quiprcise la faon dont les valeurs doivent tre transmises. Dit autrement, Java ne supporteque les directions in et return dUML.

Concepts des langages de programmation inexistants en UML

Corps des mthodesLes langages de programmation permettent tous de coder le traitement associ chaqueopration. Cest dailleurs l que rside la logique de lapplication. Curieusement, UMLne permet pas (voir encadr) de dfinir le traitement associ aux oprations des classes.Nous verrons nanmoins dans la suite de ce chapitre comment intgrer directement dansle modle UML des morceaux de code Java pour pallier ce problme.

Smantique dappel doprationChaque langage de programmation dfinit sa propre smantique dappel dopration. EnJava, par exemple, les oprations sont appeles de manire synchrone, lappelant devantattendre la fin du traitement associ lopration avant de pouvoir faire quoi que ce soitdautre.Il est cependant possible de raliser en Java des appels asynchrones en utilisant le mca-nisme de thread. En UML, aucune smantique dappel dopration nest impose. Celle-ci napparat pas dans la partie structurelle du modle. Nous verrons au chapitre 6 quilest possible de modliser diffrentes smantiques dappel dopration dans la partiecomportementale du modle.

APIChaque langage de programmation dispose de sa propre API (Application ProgrammingInterface). Cest dailleurs ce qui fait la richesse du langage de programmation.Java dispose dune API particulirement riche, qui permet, entre autres choses, dappli-quer des oprations arithmtiques lmentaires, denvoyer des messages sur Internet,dcrire et de lire dans des fichiers et dafficher des composants graphiques.UML ne propose aucune API. Il est dailleurs impossible de modliser en UML lappli-cation HelloWorld, car il nexiste aucune API permettant dafficher une chane de carac-tres lcran (quivalant du System.out.println de Java).

Traitements associs aux oprations UMLIl est de plus en plus possible de dfinir en UML les traitements associs aux oprations, notamment laide de langages tels que OCL (Object Constraint Language) ou ActionSemantic. Cela reste toutefois untravail de recherche, dont les rsultats ne sont pas encore disponibles dans les outils UML du march.Dans le cadre de ce cours, nous considrons donc quil nest pas possible de dfinir en UML les traite-ments associs aux oprations.


Concepts communs UML et aux langages de programmation qui nont pas le mme sens

HritageEn Java, seul lhritage simple entre classes est autoris. Il nest donc pas possible defaire en sorte quune classe hrite de plusieurs classes. Il est toutefois possible dutiliserle concept Java dinterface, puisquune classe Java peut raliser plusieurs interfaces Java.En UML, lhritage multiple est autoris.

Types de baseComme tout langage de programmation, Java possde un ensemble relativement fournide types de base (byte, short, int, long, float, double, boolean, char). cet ensemblepeuvent sajouter dautres types dfinis dans lAPI, tels que le type String. DepuisJava 1.5, il est en outre possible de dfinir des types numrs.UML ne propose pour sa part que peu de types de base (Integer, String, Boolean, Char,Real). La raison cela est que, historiquement, UML a t conu pour tre un langage demodlisation. Il ntait donc pas ncessaire davoir un systme de typage aussi fin quedans un langage de programmation.

Synthse entre UML et les langages de programmationNous venons de monter que UML et Java prsentaient des similitudes aussi bien que desdiffrences de smantique. Cette relation entre UML et Java vaut dailleurs pournimporte quel autre langage de programmation.La figure 3.1 reprsente une partie des similitudes et divergences des smantiques Java etUML, qui se rvleront trs importantes dans la suite de notre cours.

Passage de code Java vers les diagrammes de classesAvant de prsenter la faon dont nous pouvons construire automatiquement undiagramme de classes partir dun programme Java, il est important de bien prciserlobjectif de lopration de Reverse Engineering.

Figure 3.1 Schmatisation de la relation existant entre les smantiques UML et Java

UML Java

Traitement des oprations

Classe

ObjetAssociation

Hritage

API


Rappelons dabord ce que nous avons dj indiqu aux chapitres prcdents, savoir quele code nest que la matrialisation de la solution. Notre objectif, quand nous voulonsconstruire un diagramme de classes partir du code, est de construire le modle de lasolution partir de sa matrialisation.Le fait de ne construire que le diagramme de classes implique que nous ne construisonsquune partie du modle de la solution, en loccurrence la partie structurelle de cettesolution. De plus, le fait que le diagramme de classes reprsente scrupuleusement lastructuration du code fait que nous ne ciblons que le niveau dabstraction le plus bas,comme nous le verrons plus prcisment dans la suite de cette section.Par rapport notre reprsentation schmatique du modle dune application informati-que, lopration de Reverse Engineering permet de construire automatiquement la partiedu modle de lapplication relative la vue structurelle et ciblant le niveau dabstractionle plus bas.La figure 3.2 prsente cette proprit du Reverse Engineering.

Figure 3.2 Code, modle et opration du Reverse Engineering Structure Comportement Fonctionnalit

CODE

VUES

AB

STR

AC

TIO

N COHERENCE

Reverse Engineering


Lopration de Reverse Engineering permet uniquement de construire une partie dumodle (partie structurelle au niveau dabstraction le plus bas), qui permet, en quelquesorte, de mettre un pied dans le modle. Son intrt est, avant tout, dtablir un lienentre le code et le modle. Le code est li au modle grce cette relation.Les relations de cohrence avec les autres parties du modle permettent de lier, par tran-sitivit, le code avec lintgralit du modle. Prcisons que le Reverse Engineering nepermet en aucun cas de construire automatiquement lintgralit du modle.

Rgles de correspondance du Reverse EngineeringLopration de Reverse Engineering que nous envisageons consiste construire la partiestructurelle du modle UML au plus bas niveau dabstraction partir du code Java duneapplication.Pour pouvoir raliser cette opration automatiquement, il faut dfinir et implanter desrgles de correspondance entre les concepts Java et les concepts UML. Ces rgles decorrespondance sont trs complexes, car elles tablissent une correspondance smantiqueentre Java et UML (pont smantique).Nous prsentons dans cette section un sous-ensemble de rgles dune correspondancepossible entre Java et UML. Nous considrons que cet ensemble de rgles de correspon-dance dfinit lopration de Reverse Engineering de notre cours. Dans la suite du cours,lorsque nous parlerons de lopration de Reverse Engineering, nous nous rfreronsimplicitement cet ensemble de rgles de correspondances.

Rgles de correspondance Java vers UML1. toute classe Java doit correspondre une classe UML portant le mme nom que la

classe Java.2. toute interface Java doit correspondre une interface UML portant le mme nom que

linterface Java.3. tout attribut dune classe Java doit correspondre une proprit appartenant la

classe UML correspondant la classe Java. Le nom de la proprit doit tre le mmeque le nom de lattribut. Le type de la proprit doit tre une correspondance UML dutype de lattribut Java. Si lattribut est un tableau, la proprit peut avoir plusieursvaleurs (en fonction de la taille du tableau).

4. toute opration dune classe Java doit correspondre une opration appartenant laclasse UML correspondant la classe Java. Le nom de lopration UML doit tre lemme que celui de lopration Java. Pour chaque paramtre de lopration Java doitcorrespondre un paramtre UML de mme nom, dont la direction est in et dont letype est le type UML correspondant au type du paramtre Java.

5. Si une classe Java appartient un package Java, ce dernier doit correspondre unpackage UML correspondant au package Java qui doit contenir la classe UMLcorrespondant la classe Java.


6. Si une classe Java importe un package Java, ce dernier doit correspondre une rela-tion dimport entre le package UML de la classe UML correspondant la classe Javaet le package UML correspondant au package Java import.

7. Si une classe Java hrite dune autre classe Java, les classes UML correspondantesdoivent avoir elles aussi une relation dhritage.

8. Si une classe Java ralise une interface, la classe UML correspondante doit aussiraliser linterface UML correspondante.

Ces rgles de correspondance ne prennent pas en considration le concept UML dasso-ciation. Cela nest pas surprenant puisque ce concept nexiste pas en Java. Cependant,nous pouvons considrer quil est possible de construire une association dans le modleUML plutt quune proprit lorsquune classe Java rfrence une autre classe Java.La rgle n 3 deviendrait alors :

tout attribut dune classe Java dont le type est un type primitif doit correspondre uneproprit appartenant la classe UML correspondant la classe Java. Le nom de laproprit doit tre le mme que le nom de lattribut. Le type de la proprit doit treune correspondance UML du type de lattribut Java. Si lattribut est un tableau, laproprit peut avoir plusieurs valeurs (en fonction de la taille du tableau). tout attribut dune classe Java dont le type est une autre classe Java doit corres-pondre une association UML entre la classe UML correspondant la classe Java delattribut et la classe UML correspondant au type de lattribut Java. Cette associationdoit tre navigable vers la classe UML correspondant au type de lattribut Java. Lenom de rle de la classe correspondant au type de lattribut doit tre le mme que lenom de lattribut Java. Si lattribut Java est un tableau, lextrmit de lassociation quiporte sur la classe UML correspondant au type de lattribut Java doit spcifier queplusieurs objets peuvent tre lis. Sinon, nous considrons que la multiplicit est 0..1.

Pour finir, soulignons que les rgles de correspondance que nous venons dindiquer neprennent pas en considration le code des traitements associ aux oprations Java. Celanest pas surprenant puisque ce concept nexiste pas en UML. Cependant, il est absolu-ment ncessaire dintgrer le code dune manire ou dune autre dans le modle UMLafin de pouvoir le rutiliser dans le cadre de lopration de gnration de code que nousdtaillons au chapitre 5.Pour ce faire, nous proposons dintgrer le code des traitements associs aux oprationssous forme de note UML. Ce mcanisme est utilis par quasiment tous les outilleurs dumarch. Ainsi, cette dernire rgle sajoute notre ensemble de rgles composant notreReverse Engineering :9. Si une opration Java possde un code de traitement, alors doit correspondre une note

UML contenant ce code et qui doit tre attache lopration UML correspondant lopration Java.

tant donn que les smantiques de UML et Java diffrent, soulignons le fait quil existeplusieurs rgles de correspondance possibles. En fait, chaque outil UML du march


propose sa propre opration de Reverse Engineering, avec ses propres rgles de corres-pondance (trs souvent, ces rgles ne sont dailleurs pas explicites). Cest pourquoi, partir dun mme programme Java, il est possible dobtenir plusieurs modles UMLdiffrents.

Intrt et limites du Reverse EngineeringEn dbut de chapitre, nous avons prsent le Reverse Engineering comme une oprationpermettant de construire des diagrammes de classes partir de code Java. Nous savonsmaintenant que cette opration permet en fait la construction automatique dune partie dumodle UML (partie structurelle de bas niveau dabstraction) partir de code Java.UML fait la distinction entre modle UML et diagramme UML. Un diagramme nestquune reprsentation graphique dune partie dun modle. Il est ds lors possible dedfinir plusieurs diagrammes pour un mme modle.

Figure 3.3 Modle UML dune application informatique et ses diagrammes

Structure Comportement Fonctionnalit

VUES

AB

STR

AC

TIO

N COHERENCE

Diagramme de classes

Diagramme de squence

Diagramme de cas dutilisation


Les diagrammes reprsentent graphiquement linformation contenue dans un modle.Lopration de Reverse Engineering ne construit donc pas de diagramme de classes maisune partie du modle. Nous pouvons considrer que lopration de Reverse Engineeringconstruit la partie structurelle du modle et la stocke dans une base de donnes ou dansun fichier. Grce aux informations contenues dans la base de donnes ou dans le fichier,il est possible de construire plusieurs diagrammes de classes.Selon notre vue schmatique du modle dune application informatique, le modle UMLdune application correspond lensemble des informations contenues dans les neufparties du modle UML que nous avons prsentes au chapitre 1.De plus, UML fait correspondre un type de diagramme particulier pour chacune desvues. Par exemple, nous avons donn au chapitre prcdent le diagramme de classescorrespondant la vue structurelle dune application. Nous prsenterons dans la suite dece cours les diagrammes correspondant aux vues comportementale et fonctionnelle.UML ne donne aucune consigne quant au nombre de diagrammes quil faut laborerpour prsenter chacune des neuf parties du modle.La figure 3.3 synthtise cette distinction entre vue et diagramme et montre quil estpossible dlaborer plusieurs diagrammes par partie du modle.

Diagrammes faire aprs un Reverse EngineeringPuisque lopration de Reverse Engineering ne construit pas de diagramme mais unique-ment une partie du modle UML, il est du ressort de la personne qui a excut le ReverseEngineering dlaborer les diagrammes permettant de reprsenter graphiquement lesinformations obtenues.Aprs avoir ralis une opration de Reverse Engineering, nous prconisons doncdlaborer les diagrammes suivants, qui permettent de reprsenter graphiquement lesinformations contenues dans la partie du modle obtenue aprs Reverse Engineering : un diagramme de classes reprsentant lintgralit des informations ; un diagramme de classes reprsentant uniquement lensemble des packages et leurs

relations dimport sans montrer leur contenu ; un diagramme par package montrant uniquement le contenu dun package ; un diagramme par classe permettant de montrer le contenu de la classe et les associa-

tions et les liens dhritage vers les autres classes.

Gains offerts par le Reverse EngineeringLe Reverse Engineering est la premire opration de modlisation qui permette dobtenirun gain de productivit. En permettant de gnrer automatiquement une des neuf partiesdu modle UML, il offre, moindre cot, les deux avantages suivants : Possibilit de gnrer une documentation de la structure de lapplication laide des

diagrammes de classes labors. Cette documentation a lavantage dtre faite dans un


langage de modlisation standard trs largement diffus. Soulignons de plus que denombreux outils du march qui proposent une opration de Reverse Engineeringproposent une opration de gnration automatique de documentation. Une documen-tation UML trs technique peut donc tre obtenue rapidement.

Possibilit dlaborer les autres parties du modle UML tout en gardant une cohrenceavec le code. Cest dailleurs le principal atout du Reverse Engineering que depermettre dlaborer le lien entre une application existante et un modle. Cette opra-tion est absolument fondamentale lorsque nous voulons obtenir, partir dune applica-tion existante, les gains de productivit des oprations de modlisation que nousdtaillons dans les chapitres suivants de ce cours.

SynthseDans ce troisime chapitre, nous avons commenc par prsenter les diffrencessmantiques entre le langage UML et les langages de programmation oriente objet.Cela nous a permis de bien prciser le fait quUML possdait sa propre smantique,qui est une smantique oriente objet, mais aussi ses propres particularits.Nous avons ensuite dtaill les principes de lopration de Reverse Engineering. Cetteopration est un pont smantique entre un langage de programmation et le langageUML. Tout en soulignant le fait quil pouvait exister diffrents ponts smantiques,nous avons indiqu une faon de passer du code Java vers les diagrammes de classes.Cette faon de passer de Java UML constitue lopration de Reverse Engineeringque nous utiliserons dans la suite de ce cours.Pour finir, nous avons introduit la distinction entre les concepts de modle UML et dediagramme UML. Nous avons en particulier insist sur le fait quun diagramme ntaitque la reprsentation graphique de linformation contenue dans un modle. De ce fait,le Reverse Engineering est une opration qui permet la construction dune partie dumodle mais qui ne gnre aucun diagramme. Nous pouvons considrer que le modleest stock dans une base de donnes ou dans un fichier. Llaboration des diagrammesreste la charge de la personne qui a excut lopration de Reverse Engineering.Nous avons enfin dgag les avantages offerts par le Reverse Engineering, notammentles deux suivants : permettre de gnrer trs facilement la documentation techniquestructurelle dune application existante et permettre dtablir un lien entre le codedune application et le modle de lapplication.



TD3. Reverse EngineeringLes oprations de Reverse Engineering prsentes dans ce TD portent sur le code Javade lapplication MyAssistant donn au TD du chapitre 1. Nous appliquons ici les rgles decorrespondance Java vers UML dcrites dans le prsent chapitre.

Question 25 Effectuez le Reverse Engineering de la classe Adresse.Question 26 Effectuez le Reverse Engineering de la classe Personne.Question 27 Effectuez le Reverse Engineering de la classe Repertoire.Question 28 Pourquoi ny a-t-il pas dassociation entre la classe Repertoire et la classe

Personne alors quun rpertoire contient des personnes ?Question 29 Comment modifier les rgles du Reverse Engineering pour faire en sorte

quune association soit tablie entre la classe Repertoire et la classePersonne ?

Question 30 Effectuez le Reverse Engineering de la classe UIPersonne.Question 31 Comment introduire les classes Java dans le modle UML ? A quoi cela

sert-il ?Question 32 Est-il plus facile de comprendre une application aprs en avoir effectu le

Reverse Engineering ?Question 33 Les informations obtenues aprs Reverse Engineering sont-elles plus

abstraites que le code Java ?Question 34 Le modle obtenu par Reverse Engineering contient-il plus de diversit

que le code ?Question 35 Si vous aviez un modle UML et le code Java correspondant, comment

pourriez-vous savoir si le modle UML a t construit partir dun ReverseEngineering ?

Ce TD aura atteint son objectif pdagogique si et seulement si : Vous savez appliquer une opration de Reverse Engineering sur un code pas trop

complexe. Vous avez compris les conditions dtablissement dassociations entre classes. Vous avez conscience que le modle obtenu aprs Reverse Engineering ne vo

Documents

UML2 Pour Les Developpeurs - Cours Avec Exercices Corriges