UML 2 Pour Les Developpeurs

Xavier Blanc Isabelle Mounier
avec la contribution de Cdric Besse
pour les pour les
UML2 UML2
Cours avec exercices corrigs Cours avec exercices corrigs
dveloppeurs dveloppeurs
mon mari Jean-Luc et mes ls Julien, Romain et Clment Isabelle ma femme Virginie, mes ls Arthur et Louis et au troisime venir Xavier
Prface
UML est un langage de modlisation trs complet, qui couvre de nombreux aspects du dveloppement des logiciels, comme les exigences, larchitecture, les structures et les comportements. Depuis sa normalisation, en 1997, UML a fortement volu, passant dun langage peu formel, principalement destin la documentation, un langage sufsamment prcis pour que des applications puissent tre gnres partir des modles. Cette volution vers une plus grande prcision a cependant cr une csure entre les tenants du toutmodle , qui demandent toujours plus de formalisme, et les dveloppeurs, qui apprcient UML pour sa capacit capturer en quelques dessins les grandes lignes dune application. Le mieux tant lennemi du bien, pour satisfaire les uns, il a fallu complexier UML audel du besoin des autres. En pratique, leffort de formalisation et dabstraction requis par une utilisation complte du langage de modlisation peut souvent savrer contreproductif lorsque lcriture de code est lobjectif immdiat. Dans cet ouvrage, Xavier Blanc et Isabelle Mounier prsentent une approche de dveloppement de logiciels dans laquelle modlisation et programmation se compltent harmonieusement. Leur dmarche me semble trs pertinente, car elle permet aux dveloppeurs de bncier 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 apparatrait comme une activit subalterne, les auteurs nous montrent comment la modlisation et la programmation peuvent sutiliser de manire conjointe et complmentaire. UML pour le dveloppeur est le fruit de lexprience de Xavier et Isabelle, la conuence des modles et du code. Leur approche pragmatique et leur dmarche mthodologique bien dnie seront trs utiles aux dveloppeurs soucieux de concilier les vues abstraites 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 (Unied Modeling Language) est aujourdhui le langage de modlisation dapplications informatiques le plus important du march. Il est support par la quasi-totalit des outils de dveloppement, lesquels permettent ldition de modles UML et offrent des capacits telles que la gnration de code, de test et de documentation, le suivi dexigences ou encore le Reverse Engineering. Pour autant, ce langage reste trs complexe et nest pas facile assimiler, surtout lorsque nous souhaitons obtenir rapidement un gain de productivit. La raison cela est que lapproche classique dutilisation dUML, que nous nommons UML pour larchitecte, vise surtout utiliser les modles UML comme des moyens de rexion, dchange et de communication entre les membres dune mme quipe de dveloppement. Cette approche suit toutes les phases du cycle de vie des applications. La gnration de code narrive alors qu la n et nest rentable que si nous avons respect scrupuleusement toutes les phases antrieures. La difcult de cet exercice nous fait mieux comprendre pourquoi les gains de productivit ne sont que rarement obtenus. Une autre approche UML, que nous nommons UML pour le dveloppeur, est dj identie par quelques outilleurs du march. Davantage adapte au dveloppeur quau travail en quipe, cette approche vise obtenir des gains de productivit trs rapidement. Lide principale la base de cette approche consiste effectuer des allers-retours entre modles UML et code dans lobjectif dutiliser conjointement les meilleurs avantages de chacun des deux mondes (modle et code). Ainsi, lcriture dalgorithmes, la compilation et lexcution sont laisses au niveau des langages de programmation, tandis que la dcoupe en packages ou lapplication de patrons de conception seffectue au niveau des modles UML. Des synchronisations sont effectues entre les modles et le code an dassurer une cohrence de lensemble. Cette approche trs pragmatique offre rapidement de forts gains de productivit. Ces deux approches opposes compliquent lapprentissage dUML pour toute personne dsireuse de savoir comment utiliser ce langage dans son propre contexte. De plus, tous les ouvrages existants adressent principalement lapproche UML pour larchitecte et ne font que peu de cas des mcanismes liant UML au code des applications. Ltudiant, tout comme le dveloppeur de mtier, ne peuvent ds lors mesurer pleinement les avantages de ce langage pour leur contexte, qui porte essentiellement sur le dveloppement du code des applications.
VIII
UML pour les dveloppeurs
Cest pourquoi nous prsentons dans cet ouvrage un cours exclusivement ddi lapproche UML pour le dveloppeur. Notre objectif est de montrer la complmentarit que peut offrir UML nimporte quel langage de programmation. Nous prsentons dans chaque cas les gains de productivit que nous pouvons en obtenir.
Une approche contre-pied

Le droulement pdagogique de ce cours est volontairement contre-pied des cours UML classiques. Alors que ces derniers commencent invariablement par prsenter les fameux diagrammes de cas dutilisation et nissent par la gnration de code, nous proposons linverse, en commenant par le code et en nissant par les diagrammes de cas dutilisation. Notre objectif est de mettre au premier plan les mcanismes UML qui offrent directement des gains de productivit et den mesurer les impacts. Pour autant, les principales notions UML auront t introduites et commentes la n du cours.
Organisation de ce cours
Le plan de ce cours est le suivant : 1. Un curieux besoin de modles : ce chapitre prsente les principaux avantages des modles UML an de bien faire comprendre les relations entre modle et code. Nous y dnissons la notion de niveau dabstraction qui permet de reprsenter une mme application suivant diffrentes vues. 2. Diagrammes de classes UML : ce chapitre prsente le plus employ des diagrammes UML. Ce chapitre nest pas un guide de rfrence du diagramme de classes. Nous prsentons les concepts ncessaires dans le contexte de ce cours. 3. Reverse Engineering : ce chapitre prsente les principes du Reverse Engineering, qui consiste construire automatiquement un modle UML partir de code. Nous dnissons 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 de restructuration dapplications effectuables sur des modles UML. Nous expliquons le rle des patrons de conception et comment les appliquer sur un diagramme de classes. 5. Gnration de code : ce chapitre prsente les principes de la gnration de code partir de modles UML. Nous dnissons un ensemble de rgles permettant de gnrer du code partir dun diagramme de classes. 6. Diagrammes de squences : ce chapitre prsente les diagrammes de squence. Nous expliquons en quoi ces diagrammes sont ncessaires pour mieux comprendre le comportement dune application. Nous insistons sur le fait quils ne contiennent pas linformation ncessaire la gnration de code.
Avant-propos
IX
7. Diagrammes de squences et tests : ce chapitre prsente lutilisation des diagrammes de squence pour la gnration de tests. Nous expliquons les principes du test dapplication et sa mise en uvre par lintermdiaire de diagrammes de squence de test. 8. UML et les plates-formes dexcution : ce chapitre prsente les relations entre UML et les plates-formes dexcution an de bien faire comprendre la capacit dabstraction des modles UML. Nous insistons sur le fait quil est important, pour une mme application, davoir des modles indpendants de la plate-forme dexcution et dautres plus troitement lis cette dernire. 9. Diagrammes de cas dutilisation : ce chapitre prsente les diagrammes de cas dutilisation. Ils sont utiliss pour reprsenter les fonctionnalits dune application quel que soit le niveau dabstraction considr. 10. Dveloppement avec UML : ce chapitre prsente une mthode de dveloppement avec UML permettant dobtenir lensemble des diagrammes ncessaires la reprsentation dune application Nous partons cette fois de la description de lapplication et nous expliquons lensemble des tapes suivre pour obtenir le code de lapplication tout en ayant construit lensemble des diagrammes ncessaires pour faire le lien entre tous les niveaux dabstraction. Pour rendre plus concrte les relations entre code et modle, nous avons choisi de baser ce cours sur le langage Java. Tous les mcanismes de gnration de code ou de Reverse Engineering que nous prsentons sappuient donc sur Java. Les principes que nous prsentons dans ce cours sont cependant transposables vers dautres langages de programmation. Chaque cours est suivi dun ensemble dexercices complmentaires du cours. Nous soulignons 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 ayant des connaissances en programmation par objets et dsireux de dcouvrir les bnces du langage UML pour le dveloppement dapplications. Il ne sagit pas dun guide de rfrence sur UML. Chaque notion importante dans le contexte du dveloppement avec UML est introduite par un exemple, et chaque chapitre se clt par une srie dexercices (91 au total) avec corrigs, qui permettront au lecteur de tester ses connaissances. Louvrage sadresse aussi aux enseignants dsireux de transmettre les principes de base des langages de modlisation selon une approche pragmatique, en liaison avec les techniques classiques de dveloppement dapplications.
Table des matires

Prface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Remerciements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Avant-propos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Une approche contre-pied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Organisation de ce cours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . qui sadresse ce cours ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CHAPITRE 1
III V VII VIII VIII IX
Un curieux besoin de modles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Construction dapplications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Les modles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CHAPITRE 2
1 1 4 6 7
Diagrammes de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Vue structurelle du modle UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Paradigme orient objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Concepts lmentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Associations entre classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Concepts avancs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CHAPITRE 3
13 13 13 14 19 21
Reverse Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Smantiques UML et Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diffrences des smantiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27 27 28
XII
Synthse entre UML et les langages de programmation . . . . . . . . . . . . . . .
30 30 32 34 35
Passage de code Java vers les diagrammes de classes . . . . . . . . . . . . . . Rgles de correspondance du Reverse Engineering . . . . . . . . . . . . . . . . . . Intrt et limites du Reverse Engineering . . . . . . . . . . . . . . . . . . . . . . . . Diagrammes faire aprs un Reverse Engineering . . . . . . . . . . . . . . . . . . .
CHAPITRE 4
Rtroconception et patrons de conception . . . . . . . . . . . . . . . . . .

Identication des dpendances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Quest-ce quune dpendance ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact des cycles de dpendances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Casser les cycles de dpendances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Patron de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le patron de conception Observer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CHAPITRE 5
39 39 40 41 43 45 45
Gnration de code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DUML Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UML vers Java et Java vers UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Approches UML et code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cycle de dveloppement UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CHAPITRE 6
51 51 54 56 57
Diagrammes de squence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Vue comportementale du modle UML . . . . . . . . . . . . . . . . . . . . . . . . . . Concepts lmentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le temps dans les diagrammes de squence . . . . . . . . . . . . . . . . . . . . . . . . Liens avec la vue structurelle du modle . . . . . . . . . . . . . . . . . . . . . . . . . Objet et classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagramme et modle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Concepts avancs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interactions et gnration de code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fragment dinteraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Limites intrinsques des interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63 63 64 66 68 68 69 70 70 72 72
Table des matires
XIII
CHAPITRE 7
Diagrammes de squence de test . . . . . . . . . . . . . . . . . . . . . . . . . . .

Les tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Comment utiliser les tests ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . criture de cas de test partir dun modle UML . . . . . . . . . . . . . . . . . Cas de test abstrait et interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cas de test excutables et interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CHAPITRE 8
77 77 79 80 80 81
Plates-formes dexcution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Java dans UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modles 100 % UML et modles UML pour Java . . . . . . . . . . . . . . . . . . . UML productif ou prenne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Niveaux conceptuel et physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Abstraction de la plate-forme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Niveaux dabstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cycle de dveloppement UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intgration des deux niveaux dans le cycle . . . . . . . . . . . . . . . . . . . . . . . . . Approches possibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CHAPITRE 9
87 87 87 88 90 90 91 92 92 92
Diagrammes de cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Vue fonctionnelle du modle UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fonctionnalits dune application oriente objet . . . . . . . . . . . . . . . . . . . . . Concepts lmentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Liens avec les autres parties du modle . . . . . . . . . . . . . . . . . . . . . . . . . . Concepts avancs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Concepts avancs relatifs aux cas dutilisation . . . . . . . . . . . . . . . . . . . . . . Concept avanc relatif aux acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CHAPITRE 10
97 97 97 98 100 101 101 104
Dveloppement avec UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Analyse et conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analyse du problme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conception de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
109 109 110 110
XIV
Comment passer du quoi au comment ? . . . . . . . . . . . . . . . . . . . . . . . . . . .
111 114 115
Mthode de dveloppement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . La mthode UML pour le dveloppeur . . . . . . . . . . . . . . . . . . . . . . . . .

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

ANNEXE 2
183
Exemple de partiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Questions de cours (4 points) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exercices (16 points) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
193 193 194 201
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
Un curieux besoin de modles
Objectifs
I Sensibiliser le lecteur la complexit intrinsque de la construction dapplications
informatiques
I Motiver le besoin de modliser pour grer cette complexit et non la simplier I Comprendre la place du modle par rapport au code
Construction dapplications
En simpliant lextrme, nous pourrions dire que la construction dune application informatique se rsume raliser du code pour rpondre au besoin dun utilisateur, aussi appel client. La gure 1.1 illustre cette simplication en prenant lexemple de Word, qui a t conu pour permettre, entre autres, ses utilisateurs dcrire des livres ou des lettres.
Figure 1.1
Simplication extrme de la ralisation dune application informatique
Besoin
Avoir un logiciel pour crire un livre ou une lettre
code
Word
Cette simplication peut tre considre comme grossire. Elle a cependant le mrite de bien rappeler la nalit de lactivit de construction dapplications informatiques, qui est de raliser le code. Pour autant, la ralisation du code nest pas la seule activit effectuer lorsque nous souhaitons construire une application. Parmi les autres activits non moins indispensables effectuer, citons notamment les suivantes : Sassurer davoir bien compris le besoin de lutilisateur an de raliser un code qui le satisfasse. Il ne faut pas se mettre la place de lutilisateur ni essayer dimaginer son besoin. Lissue fatale serait alors de raliser un code ne satisfaisant pas lutilisateur. Sassurer davoir ralis un code facilement modiable, permettant de prendre en compte des volutions futures. Dnir larchitecture de lapplication (dnition de ses diffrents composants, indpendamment du langage de programmation) an de bien comprendre les relations entre les composants de lapplication. Raliser une batterie de tests an de mesurer, dune certaine manire, la qualit du code. Effectuer un suivi des besoins de lutilisateur an dintgrer des amliorations. Effectuer des corrections de bogues. La prsence de bogues tant invitable, il faut la grer plutt que la subir. crire la documentation utilisateur. crire la documentation dinstallation de lapplication. crire la documentation de lapplication an quune autre quipe de dveloppeurs puisse reprendre le dveloppement. Effectuer des tests de monte en charge an de mesurer les capacits de rsistance et la performance de lapplication. Effectuer une sparation des tches de dveloppement an de raccourcir les dlais de livraison de lapplication. Ces activits visent mieux structurer lensemble des tches effectuer lors de la construction dune application. Notons, de plus, que certaines activits dpendent dautres et quil faut parfois imprativement effectuer une activit avant den dmarrer une autre. La gure 1.2 prsente une vision de lensemble de ces activits et de leur entrelacement (chaque che prcise une dpendance dans la ralisation des activits). Cette gure fait bien ressortir la complexit intrinsque de la construction dune application. Nous voyons clairement quil y a beaucoup dactivits raliser et que lordre de ralisation de ces activits nest pas trivial.
Un curieux besoin de modles CHAPITRE 1
Besoin
Rutilisation Analyse Evolution
Impact Architecture Sparation du dveloppement Ralisation
Tests
Intgration
Solution Mise en prproduction Maintenance
Mise en production
Test de monte en charge
Figure 1.2
Vision dune partie des activits raliser pour construire une application
Pour faire face cette complexit de construction des applications informatiques, lingnierie logicielle propose depuis plusieurs annes des mthodes et des techniques permettant de rpondre aux questions suivantes : Quand raliser une activit ? Qui doit raliser une activit ? Quoi faire dans une activit ? Comment raliser une activit ?
Ces questions synthtisent grosso modo le problme de la construction dapplications informatiques. Les deux premires visent identier et organiser les diffrentes activits ncessaires la construction dune application informatique. Les deux dernires visent bien dnir les travaux devant tre raliss dans chacune des activits. Ltendue de la tche et lvolution constante des technologies nous font mieux comprendre pourquoi lingnierie logicielle est un domaine ouvert, dans lequel nombre de problmes restent encore rsoudre. Dans le cadre de ce cours, nous nous focalisons uniquement sur les activits relatives au code (gnration, analyse, documentation, tests, etc.). De plus, nous ne traitons quasiment pas les deux questions relatives lorganisation des activits (quand et qui). Notre objectif est de montrer en quoi les diffrentes techniques de modlisation UML (quoi et comment) permettent dobtenir rapidement un gain de productivit.
Le code
Nous avons introduit la section prcdente un ensemble non exhaustif dactivits quil est ncessaire de raliser pour construire une application informatique. Dans cet ensemble, la ralisation du code napparat que comme une activit parmi dautres. Cependant, comme nous lavons indiqu, la ralisation du code reste la nalit. Toutes les autres activits visent soit faciliter cette ralisation, soit loptimiser, soit permettre son volution. Le code occupe donc une place particulire dans la construction dune application informatique, mais laquelle exactement ? Une premire certitude est que, pour excuter une application, il faut la coder. Le code est donc absolument ncessaire lexcution des applications. Peut-on dire pour autant que le 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 application informatique : 1. Question. Comment le code peut-il tre utilis pour faciliter la maintenance des applications informatiques ? Rponse. Nous pourrions penser commenter le code an de faciliter la maintenance, mais il faudrait alors dnir le niveau de dtail adquat. La charte Linux propose, par exemple, de ne pas surdocumenter le code, car celui-ci devient vite illisible. Dans le projet Linux, les commentaires sont utiliss pour spcier des travaux 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 pour faciliter la maintenance. 2. Question. Comment pouvons-nous retrouver les fonctionnalits dune application en lisant le code ?
Rponse. Cest un travail difcile, qui ne peut tre automatis. Il est ncessaire de constituer une documentation diffrente du code pour expliquer dautres personnes les fonctionnalits de lapplication. 3. Question. Comment pouvons-nous dcrire la faon de mettre en production une application ? Rponse. Le code ne sert rien pour cela. Il est ncessaire de fournir une documentation 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 documentation dutilisation. Ces quelques questions-rponses permettent de comprendre, dune part, que le code occupe une place indispensable dans la construction dune application et, dautre part, quil ne permet pas, lui seul, de reprsenter toute lapplication. Il est ncessaire davoir dautres ressources (guide, documentation, etc.) pour supporter certaines activits de dveloppement (maintenance, installation, etc.). Pour illustrer cette diffrence entre code et application informatique, nous considrerons dans la suite du cours que la construction dune application consiste raliser une solution au problme dun utilisateur (voir gure 1.3). Le code est la matrialisation de cette solution. En dautres termes, le code seul ne suft pas.
Figure 1.3
Deuxime simplication de la ralisation dune application
Besoin
Avoir un logiciel pour crire un livre ou une lettre
Solution
Word
Code
Code source de Word
Nous considrons que, quel que soit le langage de programmation, le code a pour unique objectif dtre compil et excut. Toutes les autres informations utiles au dveloppement dune application nont pas rellement leur place dans le code.
Documentation
Ce constat de diffrence entre code et application informatique nest pas nouveau. On saccorde dailleurs aujourdhui sur un ensemble de documents ncessaires raliser pour complter le code. Le tableau 1.1 recense un sous-ensemble des documents raliser lors de la construction dune application. Ces documents sont changs entre les clients de lapplication et les diffrents membres de lquipe de dveloppement. Nous identions parmi ces derniers larchitecte, dont le rle est de concevoir les composants principaux de lapplication, le dveloppeur, dont le rle est de dvelopper les composants de lapplication, et ladministrateur, dont le rle est dinstaller lapplication an quelle puisse tre utilise par lutilisateur. Insistons nouveau sur le fait que ces documents ne peuvent tre directement intgrs au code, que ce soit sous forme de commentaire ou autre.
Tableau 1.1 Liste non exhaustive des documents ncessaires la ralisation dune application Document
Documentation utilisateur
Fonction
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 lapplication. Prsente une vision macroscopique de lapplication et liste les fonctionnalits ralises par lapplication. Ce document est rdig par lquipe de dveloppement et est destin aux utilisateurs 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. Dresse la liste des logiciels ncessaires linstallation et lexcution de lapplication. Ce document est rdig par lquipe de dveloppement et est destin aux administrateurs, an quils puissent mettre lapplication en production. Liste lensemble des tests qui ont t effectus sur lapplication. On peut de la sorte tester nouveau lapplication aprs lavoir modie et vrier 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 destin aux dveloppeurs futurs. Prcise la conception de lapplication (en terme de classes, par exemple). Ce document est rdig par lquipe de dveloppement et est destin aux dveloppeurs. 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 dveloppement.
Documentation des services offerts par lapplication Documentation darchitecture de lapplication Documentation des logiciels ncessaires lutilisation de lapplication Documentation des tests effectus
Documentation de la conception de lapplication Spcication des besoins
Cette liste donne la mesure de ltendue du problme de la documentation des applications. Il faut non seulement rdiger normment de documentations, mais surtout faire attention ce que ces documentations soient comprhensibles (an que rdacteurs et lecteurs se comprennent) et quelles soient cohrentes entre elles.
Ce problme peut tre rsum de la faon suivante : Comment rdiger les documentations an quelles soient intelligibles de manire non ambigu (en anglais ? en franais ? faut-il dnir 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 de la construction des applications.
Les modles
Avant de prciser en quoi les modles sont intressants pour la construction dapplications informatiques, il est intressant de prciser la dnition du terme modle. Le dictionnaire de la langue franaise en ligne TLFI (Trsor de la langue franaise informatis) donne les dnitions 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 structures essentielles dune ralit et capable son niveau den expliquer ou den reproduire dynamiquement le fonctionnement. Cyberntique : systme articiel dont certaines proprits prsentent des analogies avec des proprits, observes ou infres, dun systme tudi et dont le comportement est appel, soit rvler des comportements de loriginal susceptibles de faire lobjet de nouvelles investigations, soit tester dans quelle mesure les proprits attribues loriginal peuvent rendre compte de son comportement manifeste. Dans un contexte informatique, nous proposons la dnition suivante, qui synthtise les trois dnitions nonces prcdemment :
Modle (informatique et construction dapplications) : les modles dapplications informatiques sont des reprsentations, diffrents niveaux dabstraction et selon plusieurs vues, de linformation ncessaire la production et lvolution des applications.
Un modle contient donc plusieurs informations sur une application informatique. Ces informations ont toutes vocation faciliter dune manire ou dune autre la production du code de lapplication. Un modle peut, entre autres choses, prciser les diffrentes donnes manipules par lapplication (vue des donnes), prciser les diffrentes fonctionnalits directement offertes aux utilisateurs de lapplication (vue des utilisateurs) et prciser les technologies, telles que Java, utilises pour raliser lapplication (vue technique). En dautres termes, un modle est compos de plusieurs vues sur une application. Chacune de ces vues contient certaines informations sur lapplication. Ces vues peuvent cibler diffrents niveaux dabstraction, et elles doivent tre cohrentes.
La gure 1.4 schmatise un modle dapplication compos de trois vues.

Figure 1.4
Modle dune application
Vue des donnes
Vue des utilisateurs
Application
Vue technique
Les modles intgrent donc diffrentes vues, diffrents niveaux dabstraction dune mme application informatique. Lensemble des vues doit tre cohrent ; deux vues ne doivent donc pas spcier dinformation incohrente. Les modles permettent ainsi dharmoniser lensemble des documentations des applications informatiques en un unique ensemble cohrent. Pour pouvoir utiliser des modles, il faut dnir un langage de modlisation partag par tous. Nous traitons dans le cadre de ce cours du langage UML, qui est le langage de modlisation dapplications informatiques le plus largement partag aujourdhui.
Modles et code
Nous venons de voir que les modles contenaient, selon diffrentes vues et diffrents niveaux dabstraction, linformation ncessaire la production et lvolution des applications informatiques. Rappelons que le code est diffrent du modle. Il est, comme nous lavons dj indiqu, la matrialisation de la solution.
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 moins aussi dtaill que le code. Faire un modle nest pas plus facile qucrire du code. En effet, le modle contient beaucoup plus dinformation que le code. De plus, ces informations fortement diversies se doivent dtre cohrentes. Llaboration dun modle complet est donc un exercice encore plus difcile que la rdaction de code. Ne pas confondre niveau dabstraction et niveau de prcision. Nous entendons par abstraction le fait de pouvoir masquer dans une vue certaines informations inutiles par rapport lobjectif bien dni de cette vue. Par exemple, il nest pas intressant de montrer les dtails techniques Java dans la vue des donnes. Pour autant, toutes les informations de chaque vue doivent tre prcises. Les modles doivent tre productifs plutt que dclaratifs. Lobjectif des modles est de contenir linformation ncessaire la production et lvolution du code. Les informations contenues dans les modles doivent donc tre synchronises avec le code. Cest la raison pour laquelle nous considrons les modles comme des lments de production plutt que comme des lments de documentation.
Figure 1.5
VUES
Concept de modle UML dune application informatique, avec les vues, les niveaux dabstraction, les relations de cohrence et la relation avec le code
ABSTRACTION
Structure
Comportement
Fonctionnalit
COHERENCE
CODE
10
Notre cours se concentre sur le langage de modlisation UML. Plus prcisment, parmi les 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 expliquerons les relations de cohrence qui existent entre chacune de ces vues chaque niveau dabstraction. Nous prciserons de plus la relation de synchronisation qui existe entre le modle UML et le code. La gure 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 cohrence et sa relation avec le code. Nous considrons quun modle est compos de neuf parties, une partie chaque intersection dune vue et dun niveau dabstraction. Nous nous attacherons tout au long de ce cours prciser comment utiliser UML selon cette reprsentation.
Synthse
Dans ce premier chapitre, nous avons pass en revue toutes les activits ncessaires la construction dapplications informatiques et ainsi soulign la complexit intrinsque de cette tche. Rappelons que ces activits permettent uniquement de grer cette complexit, et non de la simplier. Nous avons ensuite prsent la place du code dans une application informatique, en insistant sur le fait que le code ntait que la matrialisation dune application informatique. Nous avons dtaill une partie des documents ncessaires la ralisation des applications. La dnition de lensemble de ces documents permet essentiellement de rpondre aux questions du comment et quoi laborer. Nous avons galement introduit le concept de modle. Les modles dapplications informatiques sont des reprsentations, diffrents niveaux dabstraction, de linformation ncessaire la production et lvolution des applications. Un modle contient donc un ensemble dinformations cohrentes sur une application informatique. Pour nir, nous avons prcis le concept de modle tel quil sera tudi dans le cadre de ce cours, cest--dire selon les vues structurelle , comportementale et fonctionnelle , sur trois niveaux dabstraction. Nous prsenterons de plus les relations de cohrence entre ces lments de modles ainsi que la relation de synchronisation avec le code.
11
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. Question 2. En une phrase, quels sont les rles de chacune des classes ? Peut-on dire quil existe des classes reprsentant des donnes et des classes reprsentant des interfaces graphiques ? Si oui, pourquoi et quelles sont ces classes ? Est-il possible que le numro de tlphone dune personne soit +33 1 44 27 00 00 ? Est-il possible que ladresse e-mail dune personne soit je_ne_veux_pas_donner_mon_email ? Quelles sont les fonctionnalits proposes par les menus graphiques de cette application ? Quelles sont application ? les fonctionnalits rellement ralises par cette
Question 3 Question 4 Question 5 Question 6 Question 7 Question 8
Est-il possible de sauvegarder un rpertoire dans un chier ? Si vous aviez rdiger un document dcrivant tout ce que vous savez sur cette application an quil puisse tre lu par un dveloppeur qui veut rutiliser cette application et un chef de projet qui souhaite savoir sil peut intgrer cette application, quelles devraient tre les caractristiques de votre document ? Rdigez un document prsentant lapplication MyAssistant.
Question 9
Question 10 Rdigez un document dcrivant les fonctionnalits de lapplication MyAssistant. Question 11 Rdigez un document dcrivant larchitecture gnrale de lapplication MyAssistant. Ce TD aura atteint son objectif pdagogique si et seulement si : Vous avez conscience que le code seul ne suft pas pour dcrire une application. Vous avez conscience que la construction de documentations est un travail laborieux et dlicat. Vous commencez comprendre lintrt de la modlisation.
2
Diagrammes de classes
Objectifs
I Prsenter les concepts UML relatifs la vue structurelle (diagramme de classes) I Prsenter la notation graphique du diagramme de classes UML I Expliquer la smantique des classes UML (compatible avec la smantique des
langages de programmation orients objet)
Vue structurelle du modle UML

La vue structurelle du modle UML est la vue la plus utilise pour spcier une application. Lobjectif de cette vue est de modliser la structure des diffrentes classes dune application oriente objet ainsi que leurs relations.
Paradigme orient objet

Conu lorigine, au cours des annes 1990, pour faciliter la construction dapplications orientes objet (OO), le langage UML a ensuite fortement volu jusqu sa version 2.1 actuelle. Nanmoins, UML reste toujours trs OO. Les concepts quil propose pour modliser la vue structurelle sont donc les concepts de classe et dobjet. UML dnit cependant sa propre smantique OO, laquelle ressemble la smantique des langages de programmation objet Java ou C++. Il est donc important de considrer UML comme un langage part entire, et non comme une couche graphique permettant de dessiner des applications Java ou C++.
14
UML pour les dvelopperus
Lobjectif de lensemble de ce cours tant de prsenter UML pour le dveloppeur, un minimum de connaissances du paradigme orient objet est requis. Les concepts lmentaires suivants du paradigme objet seront donc supposs connus : objet classe instance hritage polymorphisme encapsulation
Concepts lmentaires
Les concepts lmentaires que nous prsentons dans cette section sont les plus employs pour la ralisation de la vue structurelle dun modle UML.
Classe
Smantique En UML, une classe dnit la structure commune dun ensemble dobjets et permet la construction dobjets instances de cette classe. Une classe est identie par son nom. Graphique Une classe se reprsente laide dun rectangle, qui contient le nom de la classe. La gure 2.1 illustre la classe nomme Personne.
Figure 2.1
Reprsentation graphique dune classe
Personne
Interface
Smantique En UML, une interface dnit un contrat que doivent respecter les classes qui ralisent linterface. Une interface est identie par son nom. Les objets instances des classes qui ralisent des interfaces sont aussi des instances des interfaces. Une classe peut raliser plusieurs interfaces, et une interface peut tre ralise par plusieurs classes. Graphique Une interface se reprsente de deux faons : soit laide dun rectangle contenant le nom de 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 gure 2.2).
Diagrammes de classes CHAPITRE 2

Figure 2.2
15
Reprsentations graphiques dune interface
interface IPersonne
IPersonne
La relation de ralisation entre une classe et une interface est reprsente par une che pointille la tte en forme de triangle blanc. La gure 2.3 reprsente la classe Personne qui ralise linterface IPersonne.
Figure 2.3
Reprsentation graphique dune relation de ralisation
interface IPersonne
Personne
Proprit (anciennement appele attribut) dune classe ou dune interface
Smantique Les classes et les interfaces peuvent possder plusieurs proprits. Une proprit a un nom 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 les valeurs des proprits de sa classe. Graphique Les proprits dune classe ou dune interface se reprsentent dans le rectangle reprsentant la classe ou linterface. Chaque proprit est reprsente par son nom et son type. La gure 2.4 prsente la classe Personne, avec sa proprit nom de type string.
Figure 2.4
Reprsentation graphique dune proprit dune classe
Personne nom : string
Opration dune classe ou dune interface
Smantique Les classes et les interfaces peuvent possder plusieurs oprations. Une opration a un nom et des paramtres et peut lever des exceptions. Les paramtres sont typs et ont un sens (in, out, inout, return).
16
Un objet instance de la classe ou de linterface est responsable de la ralisation des oprations dnies dans la classe ou dans linterface. Si le sens dun paramtre de lopration est in, lobjet appelant lopration doit fournir la valeur du paramtre. Si le sens dun paramtre de lopration est out, lobjet responsable de lopration doit fournir la valeur du paramtre. Si le sens dun paramtre de lopration est inout, lobjet appelant lopration doit fournir la valeur du paramtre, mais celleci peut tre modie par lobjet responsable de lopration. Un seul paramtre peut avoir return comme sens, et il nest alors pas ncessaire de prciser le nom de ce paramtre. Si une opration possde un paramtre dont le sens est return, cela signie que lobjet responsable de lopration rend cette valeur comme rsultat de lopration. Lapport de la direction return par rapport la direction out est de faciliter la combinaison de fonction. Pour nir, les exceptions dune opration sont types. Il est important de souligner que les oprations UML ne dnissent pas le comportement qui sera ralis lors de linvocation de lopration. Nous verrons dans la suite du cours comment ce comportement est intgr dans le modle. Graphique Les oprations dune classe ou dune interface se reprsentent dans le rectangle reprsentant la classe ou linterface. Chaque opration est reprsente par son nom et ses paramtres. Il est aussi possible de masquer les paramtres de lopration. La gure 2.5 prsente la classe Personne avec son opration getNom.
Figure 2.5
Reprsentation graphique dune opration dune classe
Personne nom : string getNom()
Hritage entre classes
Smantique En UML, une classe peut hriter dautres classes. Lhritage entre classes UML doit tre considr comme une inclusion entre les ensembles des objets instances des classes. Les objets instances des sous-classes sont des objets instances des superclasses. En dautres termes, si une classe A hrite dune classe B, lensemble des objets instances de A est inclus dans lensemble des objets instances de B. Ce faisant, tout objet instance de A doit possder les valeurs des proprits dnies dans A et dans B et doit tre responsable des oprations dnies dans A et dans B. Nous verrons dans la suite de ce cours que la relation dhritage entre deux classes appartenant des packages diffrents dpend de certaines rgles.
17
Graphique La relation dhritage entre deux classes est reprsente par une che la tte en forme de triangle blanc. La gure 2.6 reprsente la classe Personne, qui hrite de la classe EtreVivant.
Figure 2.6
Reprsentation graphique de la relation dhritage entre classes
EtreVivant
Personne
Package
Smantique Un 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 regroups. La possibilit dtablir un lien entre des classes et des interfaces dpend du lien qui existe entre les packages qui les contiennent. Nous dtaillons ces concepts avancs la section suivante. Graphique Les packages se reprsentent laide dun rectangle possdant un onglet dans lequel est inscrit le nom du package. Les lments contenus se reprsentent dans le rectangle. La taille du rectangle sadapte la taille de son contenu. La gure 2.7 reprsente le package nomm personnel, qui contient la classe Personne.
Figure 2.7
Reprsentation graphique dun package
personnel
interface IPersonne
Personne
18
Import de package
Smantique An que les classes dun package puissent hriter des classes dun autre package ou y tre associes (voir section suivante), il faut prciser une relation dimport entre ces deux packages. La relation dimport est monodirectionnelle, cest--dire quelle comporte un package source et un package cible. Les classes du package source peuvent avoir accs aux classes du package cible. Nous revenons sur cette smantique au chapitre 4 de ce cours, mais nous pouvons dj mentionner que nous considrons comme interdits les cycles de relations dimport entre plusieurs packages. Graphique La relation dimport entre deux packages sexprime laide dune che en pointill. La chane de caractres access element inscrite au-dessus de cette che peut tre optionnellement positionne. La gure 2.8 prsente la relation dimport entre deux packages P1 et P2 contenant respectivement les classes A et B. Nous considrons ici que la classe A a besoin daccder la classe B.
Figure 2.8
Reprsentation graphique de la relation dimport entre deux packages
p1
A
p2
B
Note
Smantique Une note UML est un paragraphe de texte qui peut tre attach nimporte quel lment du modle UML (package, classe, proprit, opration, association). Le texte contenu dans la note permet de commenter llment cibl par la note. Graphique Les notes se reprsentent laide dun rectangle contenant le texte et dont un des coins est corn. Une ligne discontinue permet de relier la note llment du modle quelle cible. La gure 2.9 reprsente une note attache lopration nomme getNom().
Figure 2.9
Reprsentation graphique dune note associe une opration
Personne nom : string getNom() Cette opration permet d'obtenir le nom de la personne (proprit nom)
19
Associations entre classes

Le langage UML dnit le concept dassociation entre deux classes. Ce concept trs intressant, qui ne fait pas partie des concepts lmentaires du paradigme objet, permet de prciser les relations qui peuvent exister entre plusieurs objets. En UML, une association se fait entre deux classes. Elle a un nom et deux extrmits, qui permettent de la connecter chacune des classes associes. Lorsquune association est dnie entre deux classes, cela signie que les objets instances de ces deux classes peuvent tre relis entre eux. La gure 2.10 prsente lassociation nomme habite, qui associe les classes Personne et Adresse. Cette association signie que les objets instances de la classe Personne et les objets instances de la classe Adresse peuvent tre relis. En dautres termes, cela signie que des personnes habitent des adresses.
Figure 2.10
Reprsentation graphique dune association nomme
Personne nom : string tel[1..4]:string prenom[1..*]:string getNom() habite Adresse
Chaque extrmit de lassociation a un nom de rle, qui permet didentier chacune des classes lies dans le contexte de lassociation. La gure 2.11 reprsente la mme association en prcisant le nom des rles de chaque classe lie. Dans le contexte de cette association, la classe Personne reprsente lhabitant alors que la classe Adresse reprsente la rsidence. En dautres termes, cette association signie que les personnes habitent des adresses et quils sont les habitants de ces rsidences.
Figure 2.11
Reprsentation graphique dune association et de ses rles
Personne nom : string tel[1..4]:string prenom[1..*]:string getNom()
habitant *
habite
rsidence Adresse 1
En UML, il est possible de spcier chaque extrmit les nombres minimal et maximal dobjets devant tre relis. La gure 2.12 reprsente la mme association en prcisant les nombres minimal et maximal 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.
20
habitant * : pour 1 rsidence, il y a au minimum 0 habitant et au maximum une innit dhabitants. En UML, il est possible de rendre chacune des extrmits navigable ou non. Si une extrmit est navigable, cela signie que lobjet peut naviguer vers lautre objet auquel il est reli et ainsi obtenir les valeurs de ses proprits ou invoquer les oprations dont il est responsable. la gure 2.12, les habitants peuvent naviguer vers leurs rsidences (et pas linverse), ce qui permet dobtenir, par exemple, le numro de rue.
Figure 2.12
Reprsentation graphique dune association navigable
habitant *
habite
rsidence Adresse 1
Pour nir, il est possible en UML de prciser des smantiques de contenance sur les associations. Par exemple, il est possible de prciser sur une extrmit quune classe associe joue 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 partags entre plusieurs conteneurs, et une smantique de contenance forte, dite composition, qui permet de prciser que les lments contenus ne peuvent tre partags entre plusieurs conteneurs. Du point de vue graphique, la relation de contenance se reprsente laide dun losange sur lextrmit. Le losange est blanc pour lagrgation et noir pour la composition. La gure 2.13 prcise que la classe Personne joue un rle de conteneur pour la classe CompteBancaire dans le cadre de lassociation moyens de paiement, ce qui signie quun compte bancaire ne peut tre le moyen de paiement que dune seule personne.
titulaire 1
moyens de paiement
compteCourant CompteBancaire *
Figure 2.13
Reprsentation graphique dune association de composition
21
Concepts avancs
Les concepts lmentaires que nous venons de prsenter sont largement utiliss pour modliser la vue comportementale dune application. Les concepts avancs que nous prsentons le sont moins mais permettent cependant de faciliter la ralisation des oprations de Reverse Engineering et de gnration de code que nous prsenterons dans les chapitres suivants de ce cours.
Classe abstraite
Smantique Une classe UML peut tre abstraite. Dans ce cas, elle ne peut pas directement instancier un objet. Dans une classe abstraite, il est possible de prciser que certaines proprits et certaines oprations sont abstraites. Ce sont prcisment les valeurs de ces proprits et les responsabilits de ces oprations que les objets ne peuvent pas supporter directement. Cest la raison pour laquelle aucun objet ne peut tre directement instance dune classe abstraite. Pour que des objets soient instances dune classe abstraite, il faut obligatoirement quils soient instances dune classe non abstraite, laquelle hrite de la classe abstraite et rend non abstraites les proprits et les oprations abstraites. Graphique En UML 2.0, il nexiste pas de reprsentation graphique particulire pour les classes abstraites. En UML 1.4, il fallait mettre le nom de la classe en italique.
Multiplicit des proprits et des paramtres
Smantique Il 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 quune proprit peut avoir au minimum une valeur et au maximum une innit de valeurs revient prciser que la proprit est un tableau inni. Graphique Pour les proprits et les paramtres, les nombres minimal et maximal des valeurs apparaissent entre crochets. Le caractre * est utilis pour prciser que le nombre maximal de valeurs est inni. La gure 2.14 prsente diffrentes proprits en prcisant des nombres minimal et maximal de valeurs.
Figure 2.14
Reprsentation graphique des multiplicits des proprits
22
Visibilit des classes, des proprits et des oprations
Smantique Il est possible de prciser la visibilit des proprits et des oprations des classes. Les visibilits portent sur les accs aux proprits et aux oprations. On dit quune classe A accde la proprit dune classe B si le traitement associ une opration de A utilise la proprit de B. On dit quune classe A accde lopration dune classe B si le traitement 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 autre classe. private : la proprit ou lopration ne peuvent tre accdes que par la classe ellemme. protected : la proprit ou lopration ne peuvent tre accdes que par des classes qui hritent directement ou indirectement de la classe qui dnit la proprit ou lopration. Graphique Dans la reprsentation graphique de llment, les visibilits sont reprsentes de la faon 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 dnie par une classe est porte directement par la classe elle-mme (et non par chacun des objets). De mme, il est possible de prciser quune classe est directement responsable dune opration quelle dnit. 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 niveau classe sont soulignes.
23
Synthse
Dans ce deuxime chapitre, nous avons prsent le diagramme de classes UML qui permet de reprsenter la vue structurelle des applications informatiques. Ce chapitre ne se veut pas un guide de rfrence du diagramme de classes. Nous avons simplement prsent les concepts relatifs ce diagramme dont nous aurons besoin dans la suite du cours. En introduisant ces concepts, nous avons dtaill aussi bien leur smantique propre que la faon de la reprsenter graphiquement. Rappelons que la smantique de ces concepts est proche de celle des langages de programmation orients objet sans lui tre quivalente. Pour nir, soulignons le fait que les diagrammes de classes UML peuvent tre employs tout niveau dabstraction. Rien nempche de reprsenter une application informatique laide dune seule classe (haut niveau dabstraction) ou de reprsenter tous les composants de cette application comme des classes (bas niveau dabstraction).
TD2. Diagrammes de classes

Question 12 Dnissez la classe UML reprsentant un tudiant, caractris, entre autres, par un identiant, un nom, un prnom et une date de naissance. Question 13 Dnissez la classe UML reprsentant un enseignant, caractris, entre autres, par un identiant, un nom, un prnom et une date de naissance. Question 14 Dnissez la classe UML reprsentant un cours, caractris par un identiant, un nom, le nombre dheures de cours magistral, le nombre dheures de travaux dirigs et un nombre dheures de travaux pratiques que doit suivre un tudiant. Question 15 Dnissez les associations qui peuvent exister entre un enseignant et un cours. Question 16 Dnissez la classe UML reprsentant un groupe dtudiants en utilisant les associations. Question 17 Dnissez lassociation possible entre un groupe dtudiants et un cours. Question 18 Pensez-vous quil soit possible de dnir un lien dhritage entre les classes UML reprsentant respectivement les tudiants et les enseignants ? Question 19 Pensez-vous quil soit possible de dnir un lien dhritage entre les classes UML reprsentant respectivement les tudiants et les groupes dtudiants ?
24
Question 20 On nomme coursDeLEtudiant() lopration permettant dobtenir lensemble des cours suivis par un tudiant. Positionnez cette opration dans une classe, puis prcisez les paramtres de cette opration, ainsi que les modications apporter aux associations pralablement identies pour que votre solution soit ralisable. Question 21 On nomme coursDeLEnseignant() lopration permettant dobtenir lensemble des cours dans lesquels intervient un enseignant. Positionnez cette opration dans une classe, puis prcisez les paramtres de cette opration, ainsi que les modications apporter aux associations pralablement identies pour que votre solution soit ralisable. Question 22 Expliquez le diagramme de classes reprsent la gure 2.15.
Figure 2.15 Package planning
planning
Planning
Semaine numro:integer occupe calculerCreneauxLibres() *
5 * Salle numro:integer salle salle 1
joursOuvrables
Jours date:string nom:string ferie() calculerCreneauxLibres() 1 jours
crneaux
Creneau heureDebut:string heureFin:string
Question 23 Positionnez toutes vos classes (Etudiant, Enseignant, GroupeEtudiant) dans un package nomm Personnel.
Cours,
Question 24 Liez vos classes pour faire en sorte quun crneau soit li un cours !
25
Ce TD aura atteint son objectif pdagogique si et seulement si : Vous matrisez la notion de classe. Vous matrisez la signication des associations et hritages entre classes. Vous avez compris la rpercussion des associations entre classes sur les dpendances entre packages.
3
Reverse Engineering
Objectifs
I Prciser les diffrences smantiques entre modle UML (partie diagramme de
classes) et code (Java)
I Prsenter lopration de Reverse Engineering et en identier les gains et les limites I Prsenter la diffrence entre modle UML et diagramme UML
Smantiques UML et Java

Comme indiqu au chapitre prcdent, le langage UML est conu pour faciliter la construction dapplications orientes objet. La premire version de ce langage, qui a t dnie en 1995, a t trs fortement inuence par les concepts des langages de programmation oriente objet de lpoque, tels que C++, Smalltalk, etc. Les concepts UML de la partie relative au diagramme de classes, que nous avons prsents au chapitre prcdent, sont donc des concepts orients objet. En particulier, les concepts de classe, de proprit, dopration et de package sont partags par tous les langages de programmation oriente objet. An de bien souligner ladquation du langage UML au paradigme objet, il est intressant de rappeler que la premire lettre de lacronyme UML renvoie Unied. Ce mot prcise que le langage UML incarne lunication de quasiment tous les langages de modlisation dapplications orientes objet.
28
Diffrences des smantiques

Si UML partage une smantique commune avec les langages de programmation oriente objet, cela ne veut pas dire quil ait exactement la mme smantique que ces langages. Comme chaque langage de programmation oriente objet, UML possde sa propre smantique, laquelle prsente des diffrences signicatives avec les smantiques des langages de programmation. Nous dtaillons dans cette section une partie des diffrences entre la smantique UML et la smantique Java. Notre objectif est de montrer que les langages 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 instances dune classe B, il faut dnir un attribut de type B dans la classe A. Il est de plus possible dutiliser les tableaux Java an quun objet instance dune classe A rfrence plusieurs objets instances dune classe B. De manire similaire, UML permet de dnir une proprit de type B dans une classe A. Il est aussi possible dutiliser les multiplicits de cette proprit pour rfrencer plusieurs objets. Pour autant, le concept UML dassociation, que nous avons prsent au chapitre prcdent, nexiste pas en Java, qui ne permet que de dnir des rfrences entre les classes, ce qui est diffrent des associations. En particulier, en Java, il nest pas possible de prciser que deux rfrences appartenant deux classes correspondent la mme association et que lune est loppose de lautre. Import entre packages En Java, la notion de package nexiste qu travers la notion de classe. Il nest donc pas possible de dnir de package sans avoir au pralable dni une classe. Il nest pas non plus possible de dnir des rgles dimport entre packages, car, en Java, la relation dimport est toujours dnie entre une classe et un ensemble de classes qui peut tre identi par un nom de package. En UML, la notion de package existe indpendamment de la notion de classe. Il est de plus possible, comme nous lavons montr au chapitre prcdent, de dnir des relations dimport directement entre les packages. Direction des paramtres En Java, les valeurs des paramtres dune opration sont toujours donnes par lappelant de lopration. Lappel ne peut transmettre que la valeur de retour de lopration. De plus, si un objet est transmis comme valeur de paramtre par lappelant, lappel peut changer les valeurs des attributs de lobjet, mais non lobjet en lui-mme (il nest pas possible 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), qui prcise la faon dont les valeurs doivent tre transmises. Dit autrement, Java ne supporte que les directions in et return dUML.
Concepts des langages de programmation inexistants en UML
Corps des mthodes Les langages de programmation permettent tous de coder le traitement associ chaque opration. Cest dailleurs l que rside la logique de lapplication. Curieusement, UML ne permet pas (voir encadr) de dnir le traitement associ aux oprations des classes. Nous verrons nanmoins dans la suite de ce chapitre comment intgrer directement dans le modle UML des morceaux de code Java pour pallier ce problme.
Traitements associs aux oprations UML Il est de plus en plus possible de dnir en UML les traitements associs aux oprations, notamment laide de langages tels que OCL (Object Constraint Language) ou ActionSemantic. Cela reste toutefois un travail 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 dnir en UML les traitements associs aux oprations.
Smantique dappel dopration Chaque langage de programmation dnit sa propre smantique dappel dopration. En Java, par exemple, les oprations sont appeles de manire synchrone, lappelant devant attendre la n du traitement associ lopration avant de pouvoir faire quoi que ce soit dautre. Il est cependant possible de raliser en Java des appels asynchrones en utilisant le mcanisme de thread. En UML, aucune smantique dappel dopration nest impose. Celleci napparat pas dans la partie structurelle du modle. Nous verrons au chapitre 6 quil est possible de modliser diffrentes smantiques dappel dopration dans la partie comportementale du modle. API Chaque langage de programmation dispose de sa propre API (Application Programming Interface). Cest dailleurs ce qui fait la richesse du langage de programmation. Java dispose dune API particulirement riche, qui permet, entre autres choses, dappliquer des oprations arithmtiques lmentaires, denvoyer des messages sur Internet, dcrire et de lire dans des chiers et dafcher des composants graphiques. UML ne propose aucune API. Il est dailleurs impossible de modliser en UML lapplication HelloWorld, car il nexiste aucune API permettant dafcher une chane de caractres lcran (quivalant du System.out.println de Java).
30
Concepts communs UML et aux langages de programmation qui nont pas le mme sens
Hritage En Java, seul lhritage simple entre classes est autoris. Il nest donc pas possible de faire en sorte quune classe hrite de plusieurs classes. Il est toutefois possible dutiliser le concept Java dinterface, puisquune classe Java peut raliser plusieurs interfaces Java. En UML, lhritage multiple est autoris. Types de base Comme tout langage de programmation, Java possde un ensemble relativement fourni de types de base (byte, short, int, long, float, double, boolean, char). cet ensemble peuvent sajouter dautres types dnis dans lAPI, tels que le type String. Depuis Java 1.5, il est en outre possible de dnir 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 de modlisation. Il ntait donc pas ncessaire davoir un systme de typage aussi n que dans un langage de programmation.
Synthse entre UML et les langages de programmation

Nous venons de monter que UML et Java prsentaient des similitudes aussi bien que des diffrences de smantique. Cette relation entre UML et Java vaut dailleurs pour nimporte quel autre langage de programmation. La gure 3.1 reprsente une partie des similitudes et divergences des smantiques Java et UML, qui se rvleront trs importantes dans la suite de notre cours.
Figure 3.1
Schmatisation de la relation existant entre les smantiques UML et Java
UML
Classe API
Java
Association
Objet Traitement des oprations Hritage
Passage de code Java vers les diagrammes de classes

Avant de prsenter la faon dont nous pouvons construire automatiquement un diagramme de classes partir dun programme Java, il est important de bien prciser lobjectif de lopration de Reverse Engineering.
31
Rappelons dabord ce que nous avons dj indiqu aux chapitres prcdents, savoir que le code nest que la matrialisation de la solution. Notre objectif, quand nous voulons construire un diagramme de classes partir du code, est de construire le modle de la solution partir de sa matrialisation. Le fait de ne construire que le diagramme de classes implique que nous ne construisons quune partie du modle de la solution, en loccurrence la partie structurelle de cette solution. De plus, le fait que le diagramme de classes reprsente scrupuleusement la structuration 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 informatique, lopration de Reverse Engineering permet de construire automatiquement la partie du modle de lapplication relative la vue structurelle et ciblant le niveau dabstraction le plus bas. La gure 3.2 prsente cette proprit du Reverse Engineering.
Figure 3.2
VUES
Code, modle et opration du Reverse Engineering
Structure
Comportement
Fonctionnalit
ABSTRACTION
COHERENCE
Reverse Engineering
CODE
32
Lopration de Reverse Engineering permet uniquement de construire une partie du modle (partie structurelle au niveau dabstraction le plus bas), qui permet, en quelque sorte, de mettre un pied dans le modle. Son intrt est, avant tout, dtablir un lien entre 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 transitivit, le code avec lintgralit du modle. Prcisons que le Reverse Engineering ne permet en aucun cas de construire automatiquement lintgralit du modle.
Rgles de correspondance du Reverse Engineering

Lopration de Reverse Engineering que nous envisageons consiste construire la partie structurelle du modle UML au plus bas niveau dabstraction partir du code Java dune application. Pour pouvoir raliser cette opration automatiquement, il faut dnir et implanter des rgles de correspondance entre les concepts Java et les concepts UML. Ces rgles de correspondance sont trs complexes, car elles tablissent une correspondance smantique entre Java et UML (pont smantique). Nous prsentons dans cette section un sous-ensemble de rgles dune correspondance possible entre Java et UML. Nous considrons que cet ensemble de rgles de correspondance dnit lopration de Reverse Engineering de notre cours. Dans la suite du cours, lorsque nous parlerons de lopration de Reverse Engineering, nous nous rfrerons implicitement cet ensemble de rgles de correspondances.
Rgles de correspondance Java vers UML
1. 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 mme que le nom de lattribut. Le type de la proprit doit tre une correspondance UML du type de lattribut Java. Si lattribut est un tableau, la proprit peut avoir plusieurs valeurs (en fonction de la taille du tableau). 4. toute opration dune classe Java doit correspondre une opration appartenant la classe UML correspondant la classe Java. Le nom de lopration UML doit tre le mme que celui de lopration Java. Pour chaque paramtre de lopration Java doit correspondre un paramtre UML de mme nom, dont la direction est in et dont le type est le type UML correspondant au type du paramtre Java. 5. Si une classe Java appartient un package Java, ce dernier doit correspondre un package UML correspondant au package Java qui doit contenir la classe UML correspondant la classe Java.
33
6. Si une classe Java importe un package Java, ce dernier doit correspondre une relation dimport entre le package UML de la classe UML correspondant la classe Java et le package UML correspondant au package Java import. 7. Si une classe Java hrite dune autre classe Java, les classes UML correspondantes doivent avoir elles aussi une relation dhritage. 8. Si une classe Java ralise une interface, la classe UML correspondante doit aussi raliser linterface UML correspondante. Ces rgles de correspondance ne prennent pas en considration le concept UML dassociation. Cela nest pas surprenant puisque ce concept nexiste pas en Java. Cependant, nous pouvons considrer quil est possible de construire une association dans le modle UML 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 une proprit appartenant la classe UML correspondant la classe Java. Le nom de la proprit doit tre le mme que le nom de lattribut. Le type de la proprit doit tre une correspondance UML du type de lattribut Java. Si lattribut est un tableau, la proprit 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 correspondre une association UML entre la classe UML correspondant la classe Java de lattribut et la classe UML correspondant au type de lattribut Java. Cette association doit tre navigable vers la classe UML correspondant au type de lattribut Java. Le nom de rle de la classe correspondant au type de lattribut doit tre le mme que le nom de lattribut Java. Si lattribut Java est un tableau, lextrmit de lassociation qui porte sur la classe UML correspondant au type de lattribut Java doit spcier que plusieurs objets peuvent tre lis. Sinon, nous considrons que la multiplicit est 0..1. Pour nir, soulignons que les rgles de correspondance que nous venons dindiquer ne prennent pas en considration le code des traitements associ aux oprations Java. Cela nest pas surprenant puisque ce concept nexiste pas en UML. Cependant, il est absolument ncessaire dintgrer le code dune manire ou dune autre dans le modle UML an de pouvoir le rutiliser dans le cadre de lopration de gnration de code que nous dtaillons au chapitre 5. Pour ce faire, nous proposons dintgrer le code des traitements associs aux oprations sous forme de note UML. Ce mcanisme est utilis par quasiment tous les outilleurs du march. Ainsi, cette dernire rgle sajoute notre ensemble de rgles composant notre Reverse 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 existe plusieurs rgles de correspondance possibles. En fait, chaque outil UML du march
34
propose sa propre opration de Reverse Engineering, avec ses propres rgles de correspondance (trs souvent, ces rgles ne sont dailleurs pas explicites). Cest pourquoi, partir dun mme programme Java, il est possible dobtenir plusieurs modles UML diffrents.
Intrt et limites du Reverse Engineering

En dbut de chapitre, nous avons prsent le Reverse Engineering comme une opration permettant de construire des diagrammes de classes partir de code Java. Nous savons maintenant que cette opration permet en fait la construction automatique dune partie du modle UML (partie structurelle de bas niveau dabstraction) partir de code Java. UML fait la distinction entre modle UML et diagramme UML. Un diagramme nest quune reprsentation graphique dune partie dun modle. Il est ds lors possible de dnir plusieurs diagrammes pour un mme modle.
VUES
Structure
Comportement
Fonctionnalit
ABSTRACTION
COHERENCE
Diagramme de classes
Figure 3.3
Diagramme de squence
Diagramme de cas dutilisation
Modle UML dune application informatique et ses diagrammes
35
Les diagrammes reprsentent graphiquement linformation contenue dans un modle. Lopration de Reverse Engineering ne construit donc pas de diagramme de classes mais une partie du modle. Nous pouvons considrer que lopration de Reverse Engineering construit la partie structurelle du modle et la stocke dans une base de donnes ou dans un chier. Grce aux informations contenues dans la base de donnes ou dans le chier, il est possible de construire plusieurs diagrammes de classes. Selon notre vue schmatique du modle dune application informatique, le modle UML dune application correspond lensemble des informations contenues dans les neuf parties du modle UML que nous avons prsentes au chapitre 1. De plus, UML fait correspondre un type de diagramme particulier pour chacune des vues. Par exemple, nous avons donn au chapitre prcdent le diagramme de classes correspondant la vue structurelle dune application. Nous prsenterons dans la suite de ce cours les diagrammes correspondant aux vues comportementale et fonctionnelle. UML ne donne aucune consigne quant au nombre de diagrammes quil faut laborer pour prsenter chacune des neuf parties du modle. La gure 3.3 synthtise cette distinction entre vue et diagramme et montre quil est possible dlaborer plusieurs diagrammes par partie du modle.
Diagrammes faire aprs un Reverse Engineering

Puisque lopration de Reverse Engineering ne construit pas de diagramme mais uniquement une partie du modle UML, il est du ressort de la personne qui a excut le Reverse Engineering dlaborer les diagrammes permettant de reprsenter graphiquement les informations obtenues. Aprs avoir ralis une opration de Reverse Engineering, nous prconisons donc dlaborer les diagrammes suivants, qui permettent de reprsenter graphiquement les informations 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 associations et les liens dhritage vers les autres classes.
Gains offerts par le Reverse Engineering
Le Reverse Engineering est la premire opration de modlisation qui permette dobtenir un gain de productivit. En permettant de gnrer automatiquement une des neuf parties du 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
36
langage de modlisation standard trs largement diffus. Soulignons de plus que de nombreux outils du march qui proposent une opration de Reverse Engineering proposent une opration de gnration automatique de documentation. Une documentation UML trs technique peut donc tre obtenue rapidement. Possibilit dlaborer les autres parties du modle UML tout en gardant une cohrence avec le code. Cest dailleurs le principal atout du Reverse Engineering que de permettre dlaborer le lien entre une application existante et un modle. Cette opration est absolument fondamentale lorsque nous voulons obtenir, partir dune application existante, les gains de productivit des oprations de modlisation que nous dtaillons dans les chapitres suivants de ce cours.
Synthse
Dans ce troisime chapitre, nous avons commenc par prsenter les diffrences smantiques 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. Cette opration est un pont smantique entre un langage de programmation et le langage UML. 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 Engineering que nous utiliserons dans la suite de ce cours. Pour nir, nous avons introduit la distinction entre les concepts de modle UML et de diagramme UML. Nous avons en particulier insist sur le fait quun diagramme ntait que la reprsentation graphique de linformation contenue dans un modle. De ce fait, le Reverse Engineering est une opration qui permet la construction dune partie du modle mais qui ne gnre aucun diagramme. Nous pouvons considrer que le modle est stock dans une base de donnes ou dans un chier. Llaboration des diagrammes reste la charge de la personne qui a excut lopration de Reverse Engineering. Nous avons enn dgag les avantages offerts par le Reverse Engineering, notamment les deux suivants : permettre de gnrer trs facilement la documentation technique structurelle dune application existante et permettre dtablir un lien entre le code dune application et le modle de lapplication.
37
TD3. Reverse Engineering

Les oprations de Reverse Engineering prsentes dans ce TD portent sur le code Java de lapplication MyAssistant donn au TD du chapitre 1. Nous appliquons ici les rgles de correspondance 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 modier les rgles du Reverse Engineering pour faire en sorte quune association soit tablie entre la classe Repertoire et la classe Personne ? 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 Reverse Engineering ? 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 vous apporte rien de plus que le code, si ce nest davoir fait le premier pas vers lobtention dun modle complet de votre application.
4
Rtroconception et patrons de conception
Objectifs
I Dnir la notion de dpendance entre classes et prciser les mcanismes de rtroconception I Prsenter les patrons de conception
Identication des dpendances

Lopration de Reverse Engineering prsente au chapitre prcdent permet de construire automatiquement une partie du modle dune application existante. Nous avons dj indiqu quun des avantages de cette opration tait de permettre la gnration de documentation. Cet avantage est certes trs intressant mais reste en quelque sorte contemplatif , le modle obtenu ntant pas considr comme un lment de productivit part entire. Il nest donc pas intressant de produire du code aprs un Reverse Engineering. Lautre avantage de lopration de Reverse Engineering est de permettre ltablissement dun lien entre le code et le modle, an que des oprations de productivit sur les modles puissent tre ralises, en prenant garde de ne pas dtruire la cohrence entre le modle et le code. Nous allons prsent dtailler deux oprations de productivit que nous pouvons raliser sur les modles obtenus aprs Reverse Engineering. Le but de la premire opration est
40
de vrier et corriger les dpendances entre les classes. Celui de la seconde est dappliquer des solutions de conception largement connues des problmes dj identis. Ces deux oprations sont dites productives en ce quelles changent le modle. Il est ds lors intressant de produire du code aprs les avoir excutes.
Quest-ce quune dpendance ?

Avant de prciser techniquement ce quest une dpendance entre deux classes UML, il est important de rappeler lessence mme de ce terme. Le dictionnaire de la langue franaise en ligne TLFI (Trsor de la langue franaise informatis) donne les dnitions suivantes du mot dpendance (http://atilf.atilf.fr/tlf.htm) :
Dpendance : fait dtre li organiquement ou fonctionnellement un ensemble ou un lment dun ensemble.
Appliqu notre domaine, cela signie quune classe A dpend dune classe B si elle est lie soit organiquement (par lune de ses proprits ou lune de ses associations) ou fonctionnellement (par lune de ses oprations) un ensemble de classes ou une classe dun ensemble de classes. De plus, si une classe A dpend dune classe B, cela signie quil nest pas possible dutiliser la classe A pour, par exemple, instancier des objets sans disposer de la classe B. La relation de dpendance tant transitive (si A dpend de B et B dpend de C alors A dpend de C), nous mesurons toute limportance des dpendances dans le dveloppement dapplications orientes objet. Dun point de vue technique, nous considrons dans le cadre de ce cours quune classe A dpend dune classe B si et seulement si : A hrite de B. A est associe B, et lassociation est au moins navigable de A vers B. A possde un attribut dont le type est B. A possde une opration dont le type de lun des paramtres est B. Dun point de vue graphique, une dpendance entre deux classes se reprsente laide dune che pointille. La gure 4.1 reprsente graphiquement une dpendance entre la classe A et la classe B.
Figure 4.1
Reprsentation graphique dune dpendance entre deux classes
Rtroconception et patrons de conception CHAPITRE 4
41
Cette reprsentation ne prcise pas quelle est la cause de cette dpendance. La gure 4.2 fournit chacune des causes possibles.
Figure 4.2
Reprsentation graphique des causes dune relation de dpendance entre deux classes
B A A
b B 1
A -b : B
A operation(in b : B)
Soulignons quil est possible de faire apparatre sur un mme diagramme les relations de dpendance et les causes des relations de dpendance. Par souci de clart, nous prfrons toutefois privilgier llaboration dun diagramme ddi aux dpendances et masquant les causes des dpendances. Lobjectif dun tel diagramme est de faire ressortir uniquement les relations de dpendance entre les classes dune application.
Impact des cycles de dpendances

Dpendances entre classes
Nous avons donn la section prcdente la dnition de la dpendance entre deux classes. Le caractre principal de cette relation est que, si une classe A dpend dune classe B, il nest pas possible dutiliser A sans disposer de B. La question surgit ds lors de lintrt des dpendances mutuelles, et plus gnralement des cycles de dpendances. Si deux classes A et B dpendent mutuellement lune de lautre, cela signie quil est impossible de les sparer. Nous pouvons lgitimement nous demander sil nest pas intressant de fusionner les classes, puisque la dpendance mutuelle va lencontre des deux principes de base du paradigme objet que sont la cohrence forte et le couplage faible. Ces deux principes visent dnir des objets relativement indpendants (couplage faible) et capables de raliser par eux-mmes les oprations dont ils sont responsables (cohsion forte). Lobjectif est de rutiliser des classes dans diffrentes applications. En ralit, il ne faut pas considrer que la dpendance mutuelle ou les cycles de dpendances reprsentent des fautes de conception. Il est parfois ncessaire, voire obligatoire, dtablir des dpendances mutuelles an dassurer une navigation bidirectionnelle entre des lments lis. La gure 4.3 prsente une association navigable dans les deux sens entre les classes Personne et CompteBancaire. Cette association est la cause dune dpendance mutuelle entre ces deux classes. Pour autant, nous comprenons aisment quil serait intressant de
42
pouvoir naviguer dans les deux sens de cette association, mais nous comprenons aussi tout lintrt de garder ces deux classes et de ne pas les fusionner.
titulaire 1
moyens de paiement
Figure 4.3
Reprsentation graphique dune dpendance mutuelle entre deux classes
Dans le cadre de ce cours, nous considrons quil faut rduire autant que possible les dpendances mutuelles et les cycles de dpendances entre classes mais quil nest pas ncessaire de les interdire.
Dpendances entre packages
Comme nous lavons vu au chapitre 2, il est ncessaire dtablir une relation dimport entre deux packages lorsquil existe des associations ou des relations dhritage entre les classes quils contiennent. Il est en fait ncessaire dtablir une relation dimport entre deux packages sil existe des dpendances entre les classes quils contiennent, et ce quelle quen soit la cause. La gure 4.4 illustre le fait quil est ncessaire dtablir une relation dimport entre P1 et P2, car A dpend de B, A appartient P1 et B appartient P2. Il est en outre ncessaire dtablir une relation dimport entre P2 et P3, car B dpend de C, B appartient P2 et C appartient P3.
Figure 4.4
Dpendances entre packages
p2
B operation(in c : C)
p1
A b:B
p3
C
43
De ce fait, il semble possible davoir tablir des relations dimport mutuel entre deux packages (par exemple, si la classe C hrite de A). Or, comme indiqu au chapitre 2, nous interdisons dans le cadre de ce cours les cycles dimport entre packages parce que nous considrons quun package reprsente une unit de cohsion entre plusieurs classes. De ce fait, sil existait une relation dimport mutuel entre deux packages, cela signierait quil faudrait runir ces packages. Dans le cadre de ce cours, les dpendances mutuelles et plus gnralement les cycles de dpendances entre classes sont interdits entre les classes de plusieurs packages.
Casser les cycles de dpendances

Dans les deux sections prcdentes, nous avons prsent le concept de dpendance entre classes en prcisant quil tait envisageable dtablir des cycles de dpendances tant que ceux-ci ne traversaient pas plusieurs packages. Pour autant, il nest pas rare de devoir concevoir une application devant obligatoirement dnir deux packages et dont les classes de ces deux packages ont des dpendances mutuelles. La gure 4.5 illustre ce problme avec deux classes et deux packages.
Figure 4.5
Cycle des dpendances
p1
A
p2
B
Ce problme de conception relativement classique ncessite de casser le cycle des dpendances. Avant dintroduire le mcanisme qui permet de casser les cycles de dpendances, il est ncessaire de souligner le point suivant :
Une dpendance mutuelle indique un besoin mutuel entre plusieurs classes. Ce besoin est rel et ne peut tre supprim. Casser un cycle de dpendances ne signie donc pas changer les besoins entre les classes.
Ce point tant soulign, nous pouvons dtailler le principe de base du mcanisme permettant de casser un cycle de dpendances. Lide gnrale est de travailler sur une dpendance particulire et de changer cette dpendance en une indirection laide dune nouvelle classe et dune relation dhritage. Ce principe est illustr la gure 4.6. La partie du haut prsente la dpendance initiale sur laquelle va seffectuer lindirection. La partie du bas prsente lindirection. Soulignons que le besoin source de la dpendance na pas t supprim. Il a simplement t isol et dplac dans la classe BSup.
44
Figure 4.6
Mcanisme de suppression dun cycle de dpendances
B contient quelque chose dont A a besoin
BSup On dplace le besoin dans BSup A B
Grce ce principe, il nexiste plus de dpendance directe entre les classes A et B. Il est ds lors possible davoir deux packages P1 et P2 avec les classes A et B dans chacun des deux packages sans avoir dimport mutuel entre les packages P1 et P2. Nous pouvons donc avoir la relation de dpendance entre B et A illustre la gure 4.7.
Figure 4.7
Suppression dun cycle de dpendances entre packages
p1
BSup
p2
B
Pour pouvoir appliquer ce principe sur nimporte quel modle, il est ncessaire de procder de la faon suivante : 1. Identier la dpendance sur laquelle peut se faire lindirection (cette dpendance ne peut avoir un hritage comme cause). 2. Isoler le besoin de la dpendance dans une superclasse an de dplacer la dpendance. Par exemple, si A dpend de B car A utilise une opration de la classe B, il faut positionner cette opration dans la superclasse an de pouvoir dplacer le lien de dpendance.
45
3. tablir la relation dhritage. 4. Positionner les classes dans les packages et mettre les bonnes relations dimport. Ce mcanisme en quatre tapes peut paratre trivial, mais il ne lest en rien. La difcult principale est de pouvoir isoler dans une superclasse le besoin dune dpendance an de permettre la cration dune indirection. Cette opration de productivit est trs souvent excute aprs lexcution dune opration de Reverse Engineering. Rappelons que son objectif est de renforcer le couplage faible entre les classes et de raliser une dcoupe en package de meilleure qualit, dans la mesure o Java ninterdit pas les imports mutuels entre packages.
Patron de conception
En conception, il nest pas rare de faire face un problme qui a dj t rencontr et rsolu par dautres personnes. Rutiliser les solutions trouves par ces autres personnes permet de gagner non seulement du temps mais aussi de la qualit, pour peu que ces solutions aient t largement diffuses et corriges dventuelles erreurs. Pour rendre cette ide concrte, E. Gamma a dni le concept de patron de conception. Un patron de conception est une solution prouve qui permet de rsoudre un problme de conception trs bien identi. Soulignons quun patron de conception est un couple <problme/solution>. La solution dnie par un patron de conception nest intressante que si nous faisons face au mme problme que celui trait par le patron. Il ne faut en aucun cas vouloir appliquer les solutions dnies par les patrons de conception si nous nen rencontrons pas les problmes. E. Gamma a dni plus dune vingtaine de patrons de conception de rfrence, qui sont toujours utiliss lheure actuelle. Depuis lors, le nombre de patrons de conception reconnus ne cesse daugmenter. De ce fait, il est trs important aujourdhui, lorsque nous faisons face un problme de conception, de vrier si un patron de conception na pas dj t dni pour traiter ce problme. Le point qui nous intresse dans le cadre de ce cours est que la solution dnie par un patron est spcie laide dun diagramme de classes. Les classes de ce diagramme reprsentent des rles quil est ncessaire de faire jouer par certaines classes de lapplication. Appliquer la solution dnie par un patron de conception sur une application consiste donc identier parmi les classes de lapplication lesquelles doivent jouer les rles dnis par la solution.
Le patron de conception Observer

An de bien illustrer le concept de patron de conception, nous allons dtailler le patron de conception Observer tel que dni par E. Gamma.
46
Observer
Problme Crer un lien entre un objet source et plusieurs objets cibles permettant de notier les objets cibles lorsque ltat de lobjet source change. De plus, il faut pouvoir dynamiquement lier (ou dlier de) lobjet source autant dobjets cibles que nous le voulons. Solution La solution de ce patron est illustre la gure 4.8.
Figure 4.8
Le patron de conception Observer
Subject attach(in obs : Observer) detach(in obs : Observer) notify()
observer *
Observer +update()
ConcreteSubject state getState() setState() for all observer { update() }
subject 1
ConcreteObserver +update()
subject.getState()
Ce diagramme fait apparatre les quatre rles suivants : Le rle Observer est un rle abstrait (la classe est abstraite) qui reprsente une abstraction de lobjet cible . Sa mthode update permet de lui envoyer un message de notication de changement dtat de lobjet source . Le rle Subject est un rle abstrait qui reprsente une abstraction de lobjet source . Lassociation entre les classes Subject et Observer exprime le fait quun objet source peut tre li plusieurs objets cibles . Grce aux oprations attach et detach, il est possible dynamiquement de lier et de dlier les objets cibles . Lorsque nous appelons lopration notify, lobjet source appelle les oprations update des objets cibles auxquels il est li. Cest de cette manire que se fait la notication du changement dtat de lobjet source vers tous les objets cibles . Le rle ConcreteSubject est un rle concret qui hrite de Subject. Il reprsente lobjet source avec son tat. Cela napparat pas sur le diagramme, mais, la n du traitement associ lopration setState, il faut faire un appel lopration notify si ltat
47
de lobjet a chang. Cela permet, comme nous lavons dj indiqu, de notier tous les objets cibles du changement dtat. Le rle ConcreteObserver est un rle concret qui hrite de Observer. Lassociation entre les classes ConcreteObserver et ConcreteSubject exprime le fait quun objet cible est li lobjet source . Cela permet lobjet cible de rcuprer, aprs notication, la nouvelle valeur de ltat de lobjet source . Appliquer ce patron de conception sur une application ncessite didentier dans le modle de lapplication les classes pouvant jouer les rles de Subject, Observer, ConcreteSubject et ConcreteObserver. Si aucune classe existante ne peut jouer un des rles du patron de conception, il est envisageable de construire une nouvelle classe dans le modle. Lapplication des patrons de conception est une opration de productivit qui est trs souvent employe sur les modles. Cela permet de fournir des solutions prouves aux problmes de conception qui ont dj t rencontrs par dautres personnes.
Synthse
Dans ce chapitre, nous avons prsent deux oprations de productivit sur les modles UML. La premire a consist identier les cycles de dpendances entre les classes et les casser sils traversaient plusieurs packages. Cette opration permet damliorer la qualit de lapplication en assurant un couplage faible entre les classes de lapplication. La seconde a consist appliquer des patrons de conception. Grce ces derniers, il est possible de rutiliser les bonnes solutions permettant de rsoudre des problmes dj rencontrs. Ces deux oprations laissent entrevoir les gains offerts par UML. Cependant, elles ne sont rellement intressantes que sil est possible de gnrer du code partir du modle UML aprs les avoir excutes, puisque les deux oprations changent le modle. Celui-ci ntant plus cohrent avec le code de lapplication, il est ncessaire dactualiser le code partir du modle. Cest ce que nous verrons au chapitre suivant, qui prsente la gnration de code partir de modles UML.
48
TD4. Rtroconception et patrons de conception

La gure 4.9 reprsente les relations qui existent entre les classes Synchronisateur et Calculateur. Un calculateur permet deffectuer des calculs. Etant donn que nimporte qui peut demander un calculateur deffectuer des calculs, la classe Synchronisateur a t construite pour rguler les calculs. Les personnes qui souhaitent demander la ralisation dun calcul doivent passer par le synchronisateur (via lopration calculer()). Celui-ci distribue les calculs aux diffrents calculateurs avec lesquels il est li (cest lui qui appelle lopration calculer() sur les calculateurs). Un calculateur connat le synchronisateur auquel il est reli grce la proprit sync de type Synchronisateur. Sa valeur doit tre dtermine lors de la cration des objets de type Calculateur.
Figure 4.9
Classes Synchronisateur et Calculateur
Synchronisateur +calculer()
calculateur *
Calculateur -sync : Synchronisateur +calculer()
Exprimez en les justiant les dpendances entre les classes Synchronisateur et Calculateur. Nous souhaitons que les classes Synchronisateur et Calculateur soient dans deux packages diffrents. Proposez une solution. Nous souhaitons ajouter la classe Synchronisateur une opration ajouterCalculateur() qui permette dassigner un calculateur un synchronisateur, lidentit du calculateur tant un paramtre dentre de lopration. Dnissez cette opration. Nous souhaitons maintenant dnir une classe reprsentant une barre de progression. Cette barre afche ltat davancement du calcul (en pourcentage). Une barre de progression reoit des messages dun calculateur qui linforme que ltat davancement du calcul a chang. Dnissez cette classe. Tout comme le synchronisateur, une barre de progression doit se dclarer auprs dun calculateur. De plus, le calculateur doit offrir une opration permettant de connatre le pourcentage davancement du calcul. Dnissez les associations et oprations ncessaires. Appliquez le patron de conception Observer, et faites en sorte que ces deux classes soient dans deux packages diffrents.
49
Ce TD aura atteint son objectif pdagogique si et seulement si : Vous savez identier les dpendances entre classes. Vous savez casser les cycles de dpendances. Vous savez appliquer le patron de conception Observer.
5
Gnration de code
Objectifs
I Prsenter les rgles de gnration de code Java partir dun modle UML I Prsenter les problmes du cycle reverse/gnration I Prsenter les cycles de dveloppement avec UML
DUML Java
Nous avons compar au chapitre 3 la smantique UML avec la smantique Java. Nous avons alors propos des rgles de correspondance permettant de construire automatiquement une partie dun modle UML partir dune application Java. Soulignons que ces rgles reprsentent une faon parmi dautres de passer de Java vers UML. Elles constituent un des ponts smantiques de Java vers UML. Dans le prsent chapitre, nous allons proposer un pont smantique inverse, permettant de construire automatiquement une application Java partir dun modle UML. Ce pont permettra de raliser lopration de gnration de code Java partir de modles UML. Pour tablir ce pont, nous devons dnir un ensemble de rgles de correspondances des concepts UML vers les concepts Java.
Rgles de correspondance UML vers Java
1. toute classe UML doit correspondre une classe Java portant le mme nom que la classe UML.
52
2. toute interface UML doit correspondre une interface Java portant le mme nom que linterface UML. 3. toute proprit dune classe UML doit correspondre un attribut appartenant la classe Java correspondant la classe UML. Le nom de lattribut doit tre le mme que le nom de la proprit. Le type de lattribut doit tre une correspondance Java du type de la proprit UML. Si le nombre maximal de valeurs pouvant tre portes par la proprit est suprieur 1, lattribut Java est un tableau. 4. toute opration dune classe UML doit correspondre une opration appartenant la classe Java correspondant la classe UML. Les noms des oprations doivent tre les mmes. tant donn que Java ne supporte que les directions in et return, si lopration contient des paramtres de direction out ou inout, nous considrons quil nest pas possible de gnrer du code Java. Sinon, pour chaque paramtre de lopration UML dont la direction est in doit correspondre un paramtre de lopration Java. Les noms des paramtres doivent tre les mmes. Les types des paramtres doivent tre une correspondance Java des types des paramtres UML. Si lopration UML contient un paramtre de direction return, lopration Java doit dnir un retour qui lui correspond. Si lopration UML ne contient pas de paramtre de direction return, lopration Java retourne void. 5. Si une classe UML A est associe une classe UML B et que lassociation soit navigable, il doit correspondre un attribut dans la classe Java correspondant la classe UML A. Le nom de lattribut doit correspondre au nom du rle de lassociation. Le type de lattribut doit tre une correspondance Java de la classe UML B associe. Si lassociation spcie que le nombre maximal dobjets pouvant tre relis est suprieur 1, lattribut Java est un tableau. Si lassociation nest pas navigable, nous considrons quil nest pas possible de gnrer du code Java. 6. Si une classe UML hrite dune autre classe UML, il doit correspondre une relation dhritage (extends en Java) entre les classes Java correspondantes. Comme Java ne supporte pas lhritage multiple, si une classe UML hrite de plusieurs autres classes UML, nous considrons quil nest pas possible de gnrer du code Java. 7. Si une classe UML ralise une ou plusieurs interfaces UML, il doit correspondre une relation de ralisation entre la classe et les interfaces Java correspondantes. 8. Si une classe UML est contenue dans un package, la classe Java correspondante doit dclarer quelle appartient un package Java. Le nom du package Java doit tre le mme que le nom du package UML. 9. Si un package UML importe un autre package UML, toutes les classes Java correspondant aux classes UML incluses dans le package UML doivent dclarer un import Java vers toutes les classes Java correspondant aux classes incluses dans le package UML import. Ces rgles de correspondances ne prennent pas en compte les traitements associs aux oprations UML, car ceux-ci ne sont pas nativement dnis dans les modles. Le code
Gnration de code CHAPITRE 5
53
Java gnr ne contient donc que des squelettes de code sans comportement rel associ aux mthodes. De ce fait, lapplication gnre ne pourra jamais tre excute. Lorsque nous avons dni notre opration de Reverse Engineering, nous avons prcis que le code des traitements associs aux oprations tait intgr au modle laide de notes UML. Nous pouvons donc ajouter la rgle suivante nos rgles de gnration de code, qui ne sera exploitable que si le modle contient des notes de code (ce qui est garanti si le modle UML est obtenu partir dune opration de Reverse Engineering) : 10. Si des notes de code Java sont associes aux oprations des classes UML, ce code est recopi dans les oprations Java correspondantes. Notons que nos rgles de correspondances ne bncient pas assez de lAPI Java. Il serait possible, par exemple, damliorer la rgle n 5, qui porte sur les associations entre classes, en remplaant lutilisation du tableau (qui est utilis pour les associations permettant de relier plusieurs objets) par celle de la classe Java ArrayList, qui reprsente un tableau dynamique. Ainsi la rgle n 5 deviendrait : Si une classe UML est associe une autre classe UML et que lassociation soit navigable, il doit se trouver un attribut dans la classe Java correspondant la classe UML. Le nom de lattribut doit correspondre au nom du rle de lassociation. Si lassociation spcie que le nombre maximal dobjets pouvant tre relis est suprieur 1, le type de lattribut Java est de type ArrayList. Sinon, le type de lattribut doit tre une correspondance Java de la classe UML associe. Si lassociation nest pas navigable, nous considrons quil nest pas possible de gnrer du code Java. Notons pour nir que ces rgles de correspondances ne prennent pas en compte la smantique de contenance des associations, Java ne supportant pas un tel concept. Nous considrons donc quil est impossible de gnrer du code Java si le modle UML contient des associations dagrgation ou de composition. En rsum, les rgles de correspondances que nous venons de prsenter permettent de dcrire brivement le fonctionnement dune opration de gnration de code Java partir de modles UML. Contrairement aux rgles de lopration de Reverse Engineering, ces rgles contiennent des contraintes sur la nature des modles UML partir desquels peut se faire la gnration. Par exemple, il nest pas possible de gnrer du code Java si des classes du modle UML ont des hritages multiples ou si les oprations du modle UML utilisent les directions out ou inout. De plus, lopration de gnration de code Java nest pleinement exploitable que si elle est excute sur un modle UML qui contient des notes de code associes ses oprations (un modle obtenu partir dune opration de Reverse Engineering, par exemple). En effet, seule la rgle n 10 permet la gnration de code Java excutable. Lorsque lopration de gnration de code est excute sur un modle qui na pas de notes de code associes ses oprations, le code gnr ne contient que des squelettes de code. Soulignons pour nir que lopration de gnration de code sapplique sur la partie structurelle du modle UML au plus bas niveau dabstraction.
54
La gure 5.1 reprsente cette opration selon notre reprsentation du modle UML.
Figure 5.1
VUES
Code, modle et opration de gnration de code
Structure
Comportement
Fonctionnalit
ABSTRACTION
COHERENCE
Gnration de code
CODE
UML vers Java et Java vers UML

Nous venons de voir deux oprations qui permettent respectivement de passer de Java vers UML et de UML vers Java. Il est ds lors ncessaire de savoir si les effets de ces deux oprations sannulent. En dautres termes, obtenons-nous le mme code aprs avoir excut une opration de Reverse Engineering suivie dune opration de gnration de code ? linverse, obtenons-nous le mme modle aprs avoir excut une opration de gnration de code suivie dune opration de Reverse Engineering ? En fait, telles que nous les avons dnies, lexcution dune gnration de code suivie dun Reverse Engineering peuvent retourner un modle diffrent du modle dentre, alors que lexcution dun Reverse Engineering suivi dune gnration de code retournent toujours le mme code. La raison principale cela est que lopration de gnration de code fait disparatre les associations entre les classes UML dans le code gnr et que celles-ci ne rapparaissent
55
pas aprs une opration de gnration de code. De plus, la gnration de code utilise des classes particulires de lAPI Java, qui apparaissent dans le modle aprs lopration de Reverse Engineering. Par contre, tous les concepts Java sont intgrs dans le modle UML et se retrouvent dans le code aprs la gnration de code.
titulaire 1
moyens de paiement
Figure 5.2
Modle UML avant gnration/reverse
Par exemple, en excutant lopration de gnration de code partir du modle illustr la gure 5.2, nous obtenons le code Java suivant :
public class Personne { ArrayList compteCourant ; } public class CompteBancaire { Personne titulaire ; }
Aprs lexcution dun Reverse Engineering, ce code permet dobtenir le modle illustr la gure 5.3, qui est compltement diffrent du modle dorigine.
1 ArrayList compteCourant
Figure 5.3
titulaire Personne 1 CompteBancaire
Modle UML aprs gnration/reverse
Les effets engendrs par les oprations de gnration de code et de Reverse Engineering sont dicts par les rgles de correspondances qui dnissent ces oprations. Or, nous avons prcis que ces rgles de correspondances ntaient en aucun cas standards et que chaque outil proposait les siennes. De ce fait, il est impossible de prdire, sans connatre trs prcisment ces rgles, quel sera le rsultat obtenu aprs des excutions successives doprations de gnration de code et de Reverse Engineering. De plus, lheure actuelle, aucun outil du march ne prcise pleinement ses rgles de correspondances. Nous dconseillons donc, dans le cadre de ce cours, lexcution successive doprations de Reverse Engineering et de gnration de code, moins de savoir exactement quels en seront les effets.
56
Approches UML et code

Nous venons de voir quil ntait actuellement pas raisonnable dexcuter successivement les oprations de Reverse Engineering et de gnration de code. Pour autant, ce sont ces oprations qui permettent une synchronisation entre le code et le modle. Rappelons que notre objectif depuis le dbut de ce cours est deffectuer des oprations sur les modles (gnrer de la documentation, casser les dpendances ou appliquer des patrons de conception) et deffectuer des oprations sur le code (coder les traitements associs aux oprations, compiler et excuter). Il est donc absolument ncessaire de dnir une approche permettant de raliser, dune part, des oprations sur le code et, dautre part, des oprations sur le modle, tout en gardant une synchronisation entre le code et le modle.
Approches envisageables
Approche Code Driven Le point de dpart de cette approche est le code. Lobjectif est de ne jamais utiliser lopration de gnration de code. La cohrence entre le modle et le code est maintenue grce lopration de Reverse Engineering. Lintrt de cette approche est limit, car seules les oprations de lecture sur les modles peuvent tre utilises. Par exemple, il est possible de gnrer la documentation de lapplication, mais il nest pas possible de casser les dpendances ou dappliquer des patrons de conception sur les modles. Approche Model Driven Le point de dpart de cette approche est le modle. Lobjectif est de ne jamais utiliser lopration de Reverse Engineering. La cohrence entre le modle et le code est maintenue grce lopration de gnration de code. Lintrt de cette approche est actuellement limit, car il nest pas possible de modliser en UML les traitements associs aux oprations. La gnration de code excutable nest donc pas possible. Soulignons cependant quil est possible de suivre une approche Model Driven en intgrant directement dans le modle UML les notes de code Java an de pouvoir gnrer un code excutable. Mme si cette approche consiste intgrer du Java dans le modle UML, elle reste une approche Model Driven puisque lopration de Reverse Engineering nest jamais utilise. Son inconvnient est de devoir coder du Java dans le modle UML (les outils UML ne supportent que faiblement cela actuellement). Approche Round Trip Le point de dpart de cette approche peut tre soit le code, soit le modle. Lobjectif est dutiliser aussi bien les oprations de Reverse Engineering que de gnration de code pour assurer la synchronisation entre modle et code. Cependant, ces oprations doivent tre bien prpares et ne doivent pas tre utilises nimporte quand an de ne pas subir les consquences des modications quelles ralisent. Cette approche est actuellement la plus intressante, car elle cumule les avantages offerts par UML et par Java. Cependant,
57
elle est aussi la plus dlicate mettre en uvre, car elle ncessite une connaissance trs ne des oprations de Reverse Engineering et de gnration de code. Dans le cadre de ce cours, nous utiliserons lapproche Round Trip avec les prcautions suivantes : Les modles UML ne doivent pas contenir dhritages multiples entre classes. Les modles UML ne doivent pas contenir dassociations non navigables. Les modles UML ne doivent pas contenir dassociations dagrgation ou de composition. Les modles UML ne doivent pas contenir dassociations navigables spciant que le nombre maximal dobjets pouvant tre relis est suprieur 1. la place, nous ferons en sorte que les modles UML utilisent la classe ArrayList. Les modles UML doivent contenir une note de code attache chaque opration. Ces prcautions nous permettront de raliser successivement les oprations de Reverse Engineering et de gnration de code telles que nous les avons dnies sans risquer de ne plus avoir de synchronisation entre le modle et le code.
Cycle de dveloppement UML

Grce aux concepts que nous avons introduits jusqu prsent dans ce cours, nous pouvons dnir un cycle de dveloppement UML, dont les caractristiques sont les suivantes : Il suit une approche Round Trip, car il utilise les oprations de gnration de code et de Reverse Engineering pour assurer la synchronisation entre le modle et le code. Il prconise la cration de diffrents diagrammes de classes an de mieux prsenter la structuration de lapplication. Grce aux diagrammes de classes, il est possible de gnrer automatiquement une documentation de la structuration de lapplication un bas niveau dabstraction. Il prconise la suppression des cycles entre les packages grce lidentication des dpendances entre classes et au mcanisme permettant de casser les cycles de dpendances entre classes. Il prconise lapplication de patrons de conception sur le modle. Il contraint les modications du modle UML an que les excutions successives de gnration de code et de Reverse Engineering ne mettent pas en pril la synchronisation entre modle et code. Il prconise de spcier les traitements associs aux oprations des classes laide de code Java. Il prconise de raliser la compilation et lexcution de lapplication laide des outils Java classiques. Il nutilise que la partie structurelle au plus bas niveau dabstraction du modle de lapplication.
58
La gure 5.4 schmatise ce cycle de dveloppement UML.

Figure 5.4
Cycle de dveloppement avec UML
Modle UML Partie structurelle Bas niveau dabstraction
Documentation Dpendance Patron
Gnration de code
Reverse Engineering
Codage Code Java Compilation Excution
Ce cycle de dveloppement UML cumule donc les avantages de la modlisation et de la programmation, tout en assurant une cohrence globale du modle et du code. Grce la modlisation, il facilite la gnration de documentation, lidentication de dpendances, la correction de cycles de dpendances et lapplication de patrons de conception. Grce la programmation, il facilite le codage des traitements des oprations, la compilation et lexcution.
Synthse
Ce chapitre a introduit lopration de gnration de code Java partir dun modle UML. Cette opration est dnie laide de rgles de correspondances entre les concepts UML et les concepts Java. Nous avons ensuite soulign que les oprations de gnration de code et de Reverse Engineering ntaient pas symtriques. Les excutions successives de ces deux oprations peuvent engendrer de fortes modications dans le modle et dans le code, qui ne vont pas sans consquences nfastes sur la synchronisation entre modle et code. Nous avons indiqu les diffrentes approches qui permettent dutiliser UML dans un cycle de dveloppement. Nous avons expliqu lapproche Round Trip, prconise dans le cadre de ce cours, qui utilise les oprations de Reverse Engineering et de gnration de code sous rserve de respecter certaines contraintes de modlisation an dassurer une synchronisation entre modle et code. Pour nir, nous avons schmatis le socle fondateur de notre cycle de dveloppement avec UML en prcisant ses avantages et les diffrents points sur lesquels il apporte un gain.
59
TD5. Gnration de code

Question 42 crivez le code gnr partir de la classe Document illustre la gure 5.5.
Figure 5.5
Classe Document
Document id:integer titre:string etat:integer dfinirEtat()
Question 43 crivez le code gnr partir de la classe Bibliothque illustre la gure 5.6.
Figure 5.6
Classes Bibliothque et Document
Bibliothque ajouterDocument() listerDocument()
Document doc * id:integer titre:string etat:integer dfinirEtat()
Question 44 crivez le code gnr partir des classes Livre, CD, Revue (voir gure 5.7).
Figure 5.7
Classes CD, Livre et Revue
CD CDDB:string
Livre ISBN:string
Revue ISSN:string
60
Question 45 crivez le code gnr partir de lassociation CDdeLivre reprsente la gure 5.8 aprs avoir dni les rgles de gnration de code que vous comptez utiliser.
Figure 5.8
Association CDdeLivre
CD CDDB:string
cd *
CDdeLivre
livre 0..1
Livre ISBN:string
Question 46 crivez le code gnr partir des classes reprsentes la gure 5.9 aprs avoir dni les rgles de gnration de code que vous comptez utiliser.
Figure 5.9
Hritage multiple
Oeuvre
CD CDDB:string
Livre ISBN:string
Un mcanisme update permet de faire remonter les modications du code Java dans le modle UML avec lequel il est dj synchronis. Par exemple, considrons que le modle UML et le code Java de la classe Bibliothque sont synchroniss depuis la question 43 : si nous ajoutons dans le code lattribut nom la classe Bibliothque, alors celui-ci apparatra dans le modle UML aprs excution de lupdate. Nous considrons pour linstant que le mcanisme dupdate correspond une opration de Reverse Engineering du code Java, si ce nest que les lments du code qui napparaissaient pas dans le modle y sont directement ajouts. Question 47 Construisez le modle UML de la classe Bibliothque (dont vous avez fourni le code la question 43) obtenu par update aprs avoir ajout dans le code Java les attributs nom, adresse et type dont les types sont des String. Question 48 Nous voulons maintenant, toujours dans le code Java, changer lattribut type en attribut domaine. Pensez-vous quil soit possible, aprs un update,
61
que les deux attributs type et domaine puissent tre prsents dans le modle ? Si oui, quoi est d ce comportement bizarre ? Question 49 Proposez un nouveau mcanisme dupdate ne souffrant pas des dfauts prsents la question 48. Question 50 Proposez le mcanisme inverse de lupdate permettant de modier un modle UML dj synchronis avec du code et de mettre jour automatiquement le code Java. Question 51 Dans quelle approche de programmation par modlisation (Model Driven, Code Driven et Round Trip) ces mcanismes dupdate sont-ils fondamentaux ? Ce TD aura atteint son objectif pdagogique si et seulement si : Vous comprenez le mcanisme de gnration de code prsent. Vous avez pris conscience de la complexit et des limites dune gnration de code pour une application relle. Vous avez compris limportance du mcanisme dupdate.
6
Diagrammes de squence
Objectifs
I Prsenter les concepts UML relatifs la vue comportementale (diagramme de squence) I Prsenter la notation graphique du diagramme de squence UML I Expliquer la smantique des squences UML en prcisant le lien avec les classes UML
Vue comportementale du modle UML

Depuis le dbut de ce cours, nous navons prsent que les concepts relatifs la vue structurelle des applications. Dans le paradigme orient objet, la structure dune application est entirement dnie par ses classes et leurs relations. La vue structurelle est donc compltement couverte par les concepts UML relatifs aux classes (classe, opration, proprit, association, etc.). Rappelons que le diagramme de classes est la reprsentation graphique de cette vue. Laspect comportemental dune application oriente objet est dni par la faon dont interagissent les objets qui composent lapplication. lexcution, lobjet est lentit de base dune application. Les objets qui composent une application pendant son excution et leurs changes de messages permettent lapplication de raliser les traitements pour lesquelles elle a t dveloppe. UML propose plusieurs vues permettant de dnir les interactions entre objets. Une de ces vues permet de prsenter des exemples dinteraction entre plusieurs objets. Grce
64
ces exemples dinteractions, il est possible de mieux comprendre le comportement de lapplication ou de vrier que lexemple dinteraction se droule convenablement. Cette vue, dont la reprsentation graphique est le diagramme de squence, dnit deux concepts principaux : celui dobjet et celui de message chang entre deux objets. Une interaction permet didentier plusieurs objets et de reprsenter les messages quils schangent.
Concepts lmentaires
Cette section prsente les concepts lmentaires de la vue comportementale dun modle UML. Dans notre contexte, ces concepts sont sufsants pour exprimer des exemples dexcution dune application.
Objet
Smantique Dans une application, chaque objet peut envoyer et recevoir des messages des autres objets qui composent lapplication. En UML, les objets qui participent une interaction schangent des messages entre eux. Nous considrerons que, dans une interaction, il nexiste pas dobjet qui nchange pas de message avec dautres objets. Dans une application, tout objet est au moins instance dune classe concrte. Cette classe est celle qui a permis de construire lobjet. En UML, les objets qui participent une interaction peuvent ne pas avoir de classe dont ils sont instances. Nous appellerons ces objets des objets non typs. Les objets non typs sont utiliss dans les interactions pour spcier des objets qui ne font que demander la ralisation doprations et dont on ne se soucie pas de connatre le type. Dans une application, tout objet a un identiant. En UML, les objets qui participent une interaction peuvent ne pas avoir didentiant. Nous appellerons ces objets des objets anonymes. Les objets anonymes sont utiliss dans les interactions pour spcier des objets qui ne sont utiliss quune seule fois. Il ne sert alors rien de bien les identier. Graphique Les objets qui participent une interaction sont reprsents graphiquement dans un diagramme de squence par un carr contenant lidentiant de lobjet (si lobjet nest pas anonyme), suivi du nom de la classe dont lobjet est instance (si lobjet est typ). Attach ce carr, une ligne verticale reprsente la vie de lobjet dans le temps (laxe du temps tant dirig vers le bas du diagramme). La gure 6.1 reprsente quatre objets, dont un objet anonyme non typ, un objet anonyme typ, un objet identi non typ et un objet identi typ. Dans le cadre de ce cours, nous prconisons didentier et de typer quasiment tous les objets de toutes les interactions. Cela permet un meilleur suivi des cohrences entre les
Diagrammes de squence CHAPITRE 6

Figure 6.1
65
Reprsentation graphique des objets dans les interactions
:B
id1:
id2:B
diffrentes parties du modle. En fait, nous utilisons les objets non typs pour spcier les objets externes au systme (comme les utilisateurs), dont nous ne connaissons pas le type.
Message
Smantique Dans une application oriente objet, les objets communiquent par changes de messages. Le message le plus important est le message de demande de ralisation dopration, par lequel un objet demande un autre objet (ou lui-mme) de raliser une des oprations dont il est responsable. En thorie, avec ce message seul, il est possible de dcrire compltement le comportement dune application. UML intgre donc le message dappel dopration dans les interactions entre objets. Plus prcisment, UML propose deux messages dappel dopration : un message pour les appels synchrones (lappelant attend de recevoir le rsultat de lopration avant de continuer son activit) et un message pour les appels asynchrones (lappelant nattend pas de recevoir le rsultat de lopration et continue son activit aprs avoir envoy son message). UML propose aussi des messages de cration et de suppression dobjets an de grer le cycle de vie des objets participant une interaction. Dans une interaction UML, les objets peuvent soit exister au dbut de linteraction, soit tre crs par dautres objets pendant linteraction. Il est aussi possible de spcier des suppressions dobjets. Cellesci sont inities par des objets participant linteraction. Un objet dtruit ne peut plus recevoir de message. Graphique La gure 6.2 reprsente graphiquement les quatre messages suivants supports dans les interactions UML : Le premier message est un message de cration chang entre lobjet identi id1 et lobjet identi id2. Ce message signie que lobjet id1 cre lobjet id2. Le deuxime message est un message dappel synchrone dopration. Lobjet id1 demande lobjet id2 de raliser lopration nomme opration1. Lobjet id1 attend que lobjet id2 nisse de raliser cette opration avant de continuer son activit. Le message de n de traitement est reprsent par une che pointille.
66
Le troisime message est un message dappel asynchrone dopration. Ce message signie que lobjet id1 demande lobjet id2 de raliser lopration nomme opration2. Une mme opration sur un mme objet peut tre appele de manire synchrone et asynchrone dans une mme interaction. Il aurait donc t possible dappeler nouveau lopration opration1 mais de manire asynchrone. Lappel tant asynchrone, lobjet id1 na pas besoin dattendre la n du traitement de lopration pour continuer son activit. Le dernier message est un message de suppression. Lobjet id1 supprime lobjet id2.
Figure 6.2
Reprsentation graphique des messages dans une interaction
id1: cration id2:B
opration1
opration2 suppression
Le temps dans les diagrammes de squence

Une interaction spcie une succession dchanges de messages entre les objets participant linteraction. Le temps est donc trs important puisquil prcise lordre dexcution entre tous les messages dune mme interaction. Dans une interaction UML, le temps est gouvern par deux rgles principales (voir ciaprs). Ces rgles considrent les messages dappel synchrone dopration et de cration comme deux messages, un appel et un retour. Il y a donc une che de lobjet metteur vers lobjet rcepteur (appel) et une autre de lobjet rcepteur vers lobjet metteur (retour). Chaque message est ensuite dcompos en deux vnements, un vnement denvoi et un vnement correspondant la rception. Lenvoi est matrialis par lextrmit de dpart de la che correspondant au message et la rception par lextrmit darrive de la che. Ainsi, le temps est rgul par les rgles suivantes :
67
1. Sur laxe dun objet, tous les vnements sont ordonns du haut vers le bas. Cela entrane quun vnement arrive avant un autre vnement sil est positionn plus haut sur laxe dun mme objet. 2. Pour un mme message, lenvoi se droule toujours avant la rception. Grce ces deux rgles, il est possible de dnir un ordre partiel entre tous les vnements dune interaction UML. La gure 6.3 prsente une interaction entre trois objets qui schangent des messages dappels synchrones et asynchrones doprations.
Figure 6.3
Diagramme de squence
id1: m1
id2:B
id3:B
m2
m3
m4 m5
m6
Grce nos deux rgles, nous savons que ces changes obissent lordre suivant : Grce la rgle 1 : 1. Sur laxe de lobjet id1 : m1 (appel/envoi) avant m1 (retour/rception ) avant m3 (appel/ envoi) avant m3 (retour/rception) avant m4 (appel/envoi) avant m6 (appel/envoi). 2. Sur laxe de lobjet id2 : m1 (appel/rception) avant m2 (appel/envoi) avant m2 (retour/ rception) avant m1 (retour/envoi) avant m4 (appel/rception) avant m5 (appel/envoi). 3. Sur laxe de lobjet id3 : m2 (appel/rception) avant m2 (retour/envoi) avant m3 (appel/ rception) avant m3 (retour/envoi) avant m5 (appel/rception) avant m6 (appel/rception).
68
Grce la rgle 2 : 4. Pour tous les messages mi (x/envoi) avant mi (x/rception). Grce ces dductions, nous pouvons voir, par exemple, quil nexiste pas dordre entre
m5 (appel/envoi) et m6 (appel/envoi). Cela signie que linteraction ne prcise pas que lenvoi de lappel asynchrone de lopration m5 se fait avant lenvoi de lappel asynchrone de lopration m6, mme si le diagramme semble indiquer le contraire. Notons cependant que la rception de lappel asynchrone de lopration m5 se fait avant la rception de lappel asynchrone de lopration m6.
Liens avec la vue structurelle du modle

Nous avons insist fortement dans les premiers chapitres de ce cours sur les relations de cohrence qui existent entre les diffrentes parties dun mme modle. Nous avons pour linstant prsent les vues structurelle et comportementale dun modle UML. Nous prcisons dans cette section les rgles de cohrence entre ces deux vues.
Objet et classe
Les seules relations de cohrence que nous considrons entre les diagrammes de squence et les diagrammes de classes dans le cadre de ce cours sont les suivantes : Tout objet participant une interaction doit obligatoirement avoir son type dcrit sous forme de classe dans la partie structurelle. Nous dconseillons fortement lutilisation dobjets non typs. Tout message dappel dopration (synchrone ou asynchrone) doit cibler une opration spcie dans la vue structurelle. Cette opration doit appartenir la classe dont lobjet qui reoit le message est instance. Tout message dappel dopration (synchrone ou asynchrone) doit porter les valeurs des paramtres de lopration cible par le message. Considrons, par exemple, linteraction reprsente par le diagramme de la gure 6.4.
Figure 6.4
Objets typs dans une interaction
id1:A opration(123,"texte")
id2:B
Les rgles de cohrence entre parties de modles nous imposent davoir dans la partie structurelle la dnition des classes A et B ainsi que la dnition de lopration opration1
69
contenue dans la classe B. Notons que lopration opration1 possde deux paramtres de direction in et dont les types sont respectivement integer et string La gure 6.5 reprsente le diagramme de classes correspondant cette partie structurelle (les paramtres de lopration de la classe B sont masqus).
Figure 6.5
Classes des objets typs
B opration()
Les rgles de cohrence que nous venons de prsenter imposent des contraintes sur la partie comportementale du modle ainsi que sur la partie structurelle. Pour autant, elles nimposent aucune contrainte sur la faon de crer un modle cohrent. Il est donc parfaitement envisageable de commencer la construction dun modle cohrent par la partie comportementale puis de nir par crer une partie structurelle cohrente. Inversement, il est aussi possible de commencer par la partie structurelle puis de nir par la partie comportementale. La troisime approche possible est de construire en parallle les parties comportementale et structurelle. Nous conseillons fortement de tester chacune de ces trois approches an de trouver celle qui convient le mieux sa propre faon de penser.
Diagramme et modle
Nous avons vu au chapitre 3 la diffrence entre diagramme UML et modle UML. Rappelons quun diagramme est une reprsentation graphique dun modle et qu un modle peuvent correspondre plusieurs diagrammes. Cette relation que nous avons illustre sur la partie structurelle du modle est tout aussi importante pour la partie comportementale du modle. Un diagramme de squence est la reprsentation graphique de la partie comportementale (interaction) dun modle UML. Toute les informations (objets, messages, etc.) sont contenues dans le modle et reprsentes graphiquement laide des diagrammes. Il est donc possible de reprsenter une mme information dans diffrents diagrammes. En fait, seuls les objets sont reprsents dans plusieurs diagrammes. Cela permet de reprsenter graphiquement le fait quun mme objet participe plusieurs interactions. Lobjectif est de reprsenter diffrentes possibilits dun mme comportement. Nous conseillons, par exemple, de spcier les comportements nominaux (normal et sans erreur) et les comportements soulevant des erreurs avec les mmes objets. Lexemple illustr la gure 6.6 prsente deux interactions qui peuvent sexcuter dans une application de gestion de prts bancaires. Ces interactions font intervenir les mmes objets (le client c1 et la banque bk). Notons que nous avons spci le client avec un objet
70
non typ. La premire interaction reprsente un cas nominal : le prt est accord. La deuxime montre un cas soulevant une erreur : le prt est refus.
Figure 6.6
Deux diagrammes partageant de mmes objets
client: demande pret( 1000)
bk:Banque
cration
p1:Pret
acceptation
client: demande pret(1000)
bk:Banque
refus
Le fait quun objet appartienne plusieurs interactions na pas de consquence sur lordre entre les vnements des interactions. Il existe un ordre pour chaque interaction, et ces ordres sont indpendant les uns des autres.
Concepts avancs
Les concepts avancs que nous prsentons dans cette section permettent de bien comprendre le rle des interactions dans un modle UML vis--vis de la gnration du code. Les concepts ajouts dans la version UML 2.1 renforcent dailleurs ce rle.
Interactions et gnration de code

Mme si nous avons dj indiqu que les interactions permettaient uniquement de spcier des exemples dexcution dapplication, il est important de montrer pourquoi elles ne peuvent tre utilises pour spcier intgralement des algorithmes et ainsi servir la gnration de code. Il est important de prciser quune interaction ne dnit quune seule excution possible, alors quun algorithme dnit lensemble des excutions possibles. Pour spcier un
71
algorithme laide dinteractions, il faudrait pouvoir spcier chacune des excutions possibles sous la forme dune interaction. Il faudrait donc que lensemble des excutions possibles soit ni mais aussi que les rsultats retourns par lalgorithme ne dpendent que des valeurs donnes en entre (dterminisme) et que lalgorithme ne modie pas les tats des objets participant sa ralisation. Prenons, par exemple, lalgorithme correspondant la porte logique ET ralisant lopration boolenne ET. Celui-ci semble pouvoir tre spci intgralement laide dinteractions puisque lensemble des excutions possibles est ni, que le rsultat ne dpend que de lentre et que ltat de lobjet ne change pas aprs excution de lalgorithme. Les quatre excutions possibles de lalgorithme semblent pouvoir tre reprsentes de la manire illustre la gure 6.7.
utilisateur : add(true,true)
e1:PorteET
utilisateur: add(true,false)
e1:PorteET
true
false
utilisateur : add(false,false)
e1:PorteET
utilisateur: add(false,true)
e1:PorteET
false
false
Figure 6.7
Diagrammes de squence spciant lalgorithme de la porte logique ET
Pour pouvoir tre totalement sr que ces interactions spcient lintgralit des excutions de la porte ET, il faut savoir, dune part, que la porte ET a un comportement dterministe (le rsultat ne dpend que de lentre) et, dautre part, que lexcution de la porte ET ne modie par ltat de lobjet. En effet, si la porte ET avait un comportement indterministe ou si le comportement modiait ltat de lobjet, il ne serait pas possible de gnrer le code. Malheureusement, il nest pas possible de prciser ces informations en UML. En posant toutes ces conditions (ensemble ni dexcutions, dterminisme et pas de modication de ltat de lobjet), il serait possible de gnrer le code suivant partir des diagrammes que nous venons de prsenter :
72
public boolean add(boolean a , boolean b) { if (a && b) return true ; else if (a && !b) return false ; else if ( !a && !b) return false ; else if ( !a && b) return false ; }
En conclusion, nous pouvons dire quil est possible de spcier des algorithmes et de gnrer du code partir dinteractions si lensemble des comportements possibles est ni, si le comportement spci est dterministe et si le comportement ne modie pas les tats des objets. En dautres termes, cela nest pas impossible mais reste sufsamment rare pour ne jamais tre employ.
Fragment dinteraction
Dans UML 1.4 et les versions prcdentes, il ntait pas possible de composer des interactions entre elles, ni dintgrer une interaction dans une autre interaction. Cela posait problme parce quil ntait pas possible de spcier et de rutiliser des interactions an den construire de plus complexes. Ce problme a t compltement rsolu avec UML 2.1, qui supporte le concept de fragment dinteraction. Un fragment permet didentier une sous-partie dune interaction an que celle-ci soit rfrence par dautres interactions. Associ au concept dinteraction, UML 2.1 propose des oprateurs permettant de spcier des conditions dexcution telles que les boucles (loop) ou les tests (if then else) sur les fragments dinteractions. Grce ces nouveaux concepts, il est possible de spcier des exemples dexcution beaucoup plus complexes et beaucoup plus lisibles grce la possibilit de dcomposer les interactions en sous-interactions. Cependant, dans le contexte de ce cours, nous nutilisons pas ces concepts avancs, car nous nen avons pas besoin pour prsenter les avantages quapportent les interactions lorsque nous utilisons UML pour le dveloppement dapplications.
Limites intrinsques des interactions

Les interactions permettent uniquement de prsenter des changes de messages entre objets. Il nest donc pas possible de spcier : Les accs aux proprits des objets, moins dutiliser des oprations daccs aux proprits. Les navigations sur les associations navigables. Les crations de liens entre objets. Les appels aux oprations de classes, car aucun objet nest directement responsable de la ralisation de lopration.
73
Synthse
Nous avons montr dans ce chapitre comment la vue comportementale pouvait tre modlise en UML laide du concept dinteraction. Une interaction UML permet de spcier un exemple dexcution dune application. Plus prcisment, une interaction spcie les changes de messages effectus entre plusieurs objets qui composent lapplication. Aprs avoir prsent les concepts de base des interactions (objet et message), nous avons spci les contraintes de cohrence qui existent entre la partie structurelle et la partie comportementale du modle. Nous avons aussi prsent les diffrentes approches de construction permettant la ralisation dun modle cohrent. Nous avons en outre montr pourquoi les interactions ne permettaient pas de spcier des algorithmes et ne permettaient donc pas de gnrer du code. Nous avons en particulier insist sur le fait quune interaction ne spciait quune seule excution possible dune application. Pour nir, nous avons introduit les concepts avancs des interactions UML en prsentant notamment le concept de fragment, qui a t dni dans la version 2.0 dUML. Soulignons que nous nutiliserons pas ces concepts dans la suite de notre cours.
TD6. Diagrammes de squence UML

Lapplication ChampionnatEchecs, qui devra permettre de grer le droulement dun championnat dchecs est actuellement en cours de dveloppement. Lquipe de dveloppement na pour linstant ralis quun diagramme de classes de cette application (voir gure 6.8). La classe ChampionnatDEchecs reprsente un championnat dchecs. Un championnat se droule entre plusieurs joueurs (voir classe Joueur) et se joue en plusieurs parties (voir classe Partie). La proprit MAX de la classe ChampionnatDEchecs correspond au nombre maximal de joueurs que le championnat peut comporter. La proprit fermer permet de savoir si le championnat est ferm ou si de nouveaux joueurs peuvent sinscrire.
ChampionnatDEchecs possde les oprations suivantes :

inscriptionJoueur(in nom:string, in prnom:string) : integer permettant dinscrire un nouveau joueur dans le championnat si le nombre de joueurs inscrits
74
nest pas dj gal MAX et si le championnat nest pas dj ferm. Si linscription est autorise, cette opration cre le joueur et retourne son numro dans le championnat. gnrerPartie() : permet de fermer le championnat et de gnrer toutes les parties ncessaires. obtenirPartieDUnJoueur(in numro :integer) : Partie[*] : permet dobtenir la liste de toutes les parties dun joueur (dont le numro est pass en paramtre). calculerClassementDUnJoueur(in numro :interger) : integer permettant de calculer le classement dun joueur (dont le numro est pass en paramtre) pendant le championnat.
Figure 6.8
Classes de lapplication ChampionnatEchecs
ChampionnatDEchecs -MAX:integer -fermer:boolean +inscriptionJoueur() +gnrerParties() +obtenirPartiesDUnJoueur() +calculerClassementDUnJoueur() joueur * Joueur -numro:integer -nom:string -prnom:string
noir
blanc
partie
Partie -numro:integer -fini:boolean +jouerCoup() -verifierMat() -finirPartie()
La classe Partie reprsente une des parties du championnat. La classe Partie est dailleurs associe avec la classe ChampionnatDEchecs, et lassociation prcise quun championnat peut contenir plusieurs parties. Une partie se joue entre deux joueurs. Un joueur possde les pices blanches et commence la partie alors que lautre joueur possde les pices noires. Les associations entre les classes Partie et Joueurs prcisent cela. La proprit numro correspond au numro de la partie (celui-ci doit tre unique). La proprit fini permet de savoir si la partie a dj t joue ou pas. La classe Partie possde les oprations suivantes : jouerCoup(in coup:string) : permet de jouer un coup tant que la partie nest pas nie. Le traitement associ cette opration fait appel lopration vrifierMat an de savoir si le coup jou ne met pas n la partie. Si tel est le cas, lopration finirPartie est appele. vrifierMat() : boolean permettant de vrier si la position nest pas mat. finirPartie : permet de prciser que la partie est nie. Il nest donc plus possible de jouer de nouveaux coups.
75
La classe Joueur reprsente les joueurs du championnat. La classe Joueur est dailleurs associe avec la classe ChampionnatDEchecs, et lassociation prcise quun championnat peut contenir plusieurs joueurs. La proprit numro correspond au numro du joueur (celui-ci doit tre unique). Les proprits nom et prnom permettent de prciser le nom et le prnom du joueur. Un championnat dchecs se droule comme suit : Un administrateur de lapplication cre un championnat avec une valeur MAX. Les participants peuvent sinscrire comme joueurs dans le championnat. Ladministrateur cre lensemble des parties. Les participants, une fois inscrits, peuvent consulter leur liste de parties. Les participants, une fois inscrits, peuvent jouer leurs parties. Nous ne nous intressons qu'aux coups jous par chacun des deux joueurs. Nous ignorons l'initialisation de la partie (identication du joueur qui a les pions blancs et donc qui commence la partie). Les participants peuvent consulter leur classement.
Dans les questions suivantes, nous allons spcier des exemples dexcution de ChampionnatDEchecs avec des diagrammes de squence. Question 52 Comment modliser les administrateurs et les participants ? Question 53 Reprsentez par un diagramme de squence le scnario dexcution correspondant la cration dun championnat et linscription de deux joueurs. Vous assurerez la cohrence de votre diagramme avec le diagramme de classes fourni la gure 6.8. Question 54 Reprsentez par un diagramme de squence le scnario dexcution correspondant la cration de lensemble des parties pour le championnat cr la question 53. Vous assurerez la cohrence de votre diagramme avec le diagramme de classes fourni la gure 6.8. Question 55 Reprsentez par un diagramme de squence le scnario dexcution correspondant au droulement de la partie dchecs entre deux joueurs. Vous pouvez considrer une partie qui se termine en quatre coups. Vous assurerez la cohrence de votre diagramme avec le diagramme de classes fourni la gure 6.8.. Question 56 Est-il possible de gnrer automatiquement le code dune opration de cette application partir de plusieurs diagrammes de squence ? Question 57 Est-il possible de construire des diagrammes de squence partir du code dune application ? Une quipe de dveloppement souhaite raliser une application Calculus qui permet des utilisateurs deffectuer des oprations arithmtiques simples sur des entiers : addition, soustraction, produit, division. Cette application a aussi une fonction mmoire qui permet l'utilisateur de stocker un nombre entier qu'il pourra ensuite utiliser pour n'importe quelle opration. Les oprations peuvent directement s'effectuer sur la mmoire. Lutilisateur se connecte et ouvre ainsi une nouvelle session. Puis, dans le
76
cadre dune session, lutilisateur peut demander au systme deffectuer une suite doprations. Question 58 Utilisez des diagrammes de squences pour reprsenter les diffrents scnarios dexcution du service Calculus. Question 59 Pour chacune des instances apparaissant dans votre diagramme de classes, crez la classe correspondante. Ce TD aura atteint son objectif pdagogique si et seulement si : Vous savez laborer un diagramme de squence cohrent avec un diagramme de classes. Vous savez laborer un diagramme de classes cohrent avec un ensemble de diagrammes de squence. Vous avez compris la relation qui existe entre une interaction et du code.
7
Diagrammes de squence de test
Objectifs
I Prsenter les concepts du test I Sensibiliser la difcult de la construction dune suite de tests I Prsenter lintrt des interactions UML pour la spcication des cas de test I Prsenter le cycle de dveloppement avec UML intgrant les tests
Les tests
Grce notamment aux techniques dites XP (eXtreme Programming), les tests sont de plus en plus utiliss en dveloppement. Lide gnrale est de pouvoir tester le code que nous sommes en train de dvelopper an de nous assurer que celui-ci est correct, cest-dire quil respecte le fameux besoin du client (voir le chapitre 1). Le concept de test nest cependant pas si simple, et il est ncessaire de bien avoir en tte certaines dnitions avant de voir comment intgrer les tests dans un cycle de dveloppement avec UML. Avant de prsenter les dnitions des concepts ncessaires aux tests, il est important de savoir rpondre la question suivante : quoi sert le test ? . Pour lIEEE, le but du test est de rvler les fautes.
78
Il sensuit les dnitions suivantes : Une faute intervient quand lexcution dun logiciel fournit un rsultat autre que celui attendu (IEEE std 982 1044). Une faute est cause par une ou plusieurs dfaillances dans une implmentation (IEEE std 982 1044). Un cas de test est un test dune proprit particulire dune application. Il sagit dun scnario dexcution de lapplication exhibant une suite de stimuli et comparant les rsultats obtenus aprs stimulation de lapplication avec les rsultats attendus. Une suite de tests est un ensemble de cas de test permettant de valider lensemble des proprits dune application. En rsum, nous pouvons dire que les tests sont raliss dans lobjectif de trouver les dfaillances (bogues) dune application. Pour ce faire, chaque test (cas de test) stimule lapplication an de provoquer une ventuelle faute. Lorsquune faute est rvle, cela signie que lapplication contient une ou plusieurs dfaillances. Lide principale du test fonctionne donc sur limplication suivante : Faute rvle implique dfaillance(s) dans lapplication. partir de cette implication, nous comprenons mieux pourquoi le test a pour objectif de rvler des fautes : cest en rvlant des fautes que nous pouvons afrmer que lapplication contient des dfaillances. Soulignons que cette implication nest pas une quivalence. Ce nest pas parce quaucune faute nest rvle que nous pouvons afrmer que lapplication ne contient pas de dfaillances. Soulignons de surcrot que les tests noffrent aucun mcanisme pour trouver la raison des dfaillances dans le code de lapplication et, par voie de consquence, aucun mcanisme pour les corriger. Associs ces concepts relativement thoriques, les concepts suivants ont t dnis an de mettre en pratique lexcution du test : Un cas de test abstrait est un cas de test construit partir de la spcication de lapplication. Un cas de test excutable est un cas de test excutable sur une architecture dimplmentation cible. Un test excutable est construit partir dun test abstrait. Un testeur est une application qui contrle lexcution de lapplication tester en lui fournissant les entres et en comparant les rsultats retourns par lapplication aux rsultats prvus (cest--dire les rsultats spcis). Ainsi, an de raliser et dexcuter une suite de tests sur une application, il est ncessaire de : 1. Construire lensemble des cas de test abstraits composant la suite de tests. Ces cas de test sont bass sur la spcication de lapplication.
Diagrammes de squence de test CHAPITRE 7
79
2. Construire lensemble des cas de test excutables composant la suite de tests. Ces cas de test sont bass sur les cas de test abstraits et doivent pouvoir sexcuter sur lapplication. 3. Construire un testeur capable dexcuter la suite de tests sur lapplication an de rendre le verdict (comparaison entre les rsultats obtenus et les rsultats attendus). Nous verrons dans la suite de ce chapitre que certains environnements Open Source proposent des testeurs.
Comment utiliser les tests ?

Les dnitions que nous venons de rappeler impliquent quil faut disposer dune spcication de lapplication pour pouvoir construire les cas de test abstraits. Dans notre contexte, nous pouvons considrer que la spcication de lapplication est incluse dans le modle de lapplication. Nous avons aussi montr quil fallait disposer dune application excutable pour construire des cas de test excutables. Dans notre contexte, nous pouvons rduire lapplication excutable au code de lapplication, car seul le code est ncessaire pour pouvoir excuter lapplication. Cette distinction entre spcication de lapplication et application excutable ainsi que les relations qui existent avec les cas de test abstraits et excutables sont schmatises la gure 7.1 (les ches reprsentent les dpendances entre les lments).
Figure 7.1
Dpendances entre tests et application
Spcification de lapplication
Cas de test abstrait
Application excutable
Cas de test excutable
Cette prsentation des relations entre, dune part, les cas de test abstraits et excutables et, dautre part, la spcication de lapplication et lapplication excutable met bien en vidence limportance des cas de test abstraits. En effet, cest uniquement de leur qualit que dpend la qualit des rsultats obtenus (en terme de fautes rvles, par exemple). Si les cas de test abstraits sont mal construits et stimulent mal lapplication, aucune faute ne peut tre rvle. Les cas de test excutables
80
ne sont quun reet des cas de test abstraits an de permettre leur excution sur lapplication. De ce fait, la difcult la plus importante dans la ralisation dune suite de tests rside dans la construction des cas de test abstraits. Comment construire de bons cas de test abstraits, autrement dit comment construire des cas de test qui permettent de rvler les fautes dune application ? Ces questions relvent encore malheureusement du domaine de la recherche. Nous pourrions ajouter la question suivante : comment faire un ensemble de cas de test abstraits complet, autrement dit comment faire un ensemble de cas de test sufsamment exhaustif pour assurer une certaine qualit dune application lorsque aucune faute nest rvle ? Ces questions, tout aussi importantes que les prcdentes, sont aussi des questions de recherche. Nous ne dtaillons pas les rponses actuelles ces questions, qui sortent du contexte de ce cours. Nous pouvons nanmoins prendre conscience de leur complexit grce un exemple simple tel que celui dune application ralisant un tri alphabtique sur les cases dun tableau de chanes de caractres. Une faute possible de cette application serait de mal trier les cases du tableau. Construire un cas de test visant rvler cette faute est cependant extrmement complexe. Sur quelles chanes de caractres faut-il tester lapplication ? Sur quelles tailles de tableau faut-il tester lapplication ? Quel serait un ensemble de cas de test abstraits sufsamment complet pour pouvoir assurer dans une certaine mesure que lapplication ralise correctement le tri de nimporte quel tableau ?
criture de cas de test partir dun modle UML

Le test apporte un gain signicatif dans le dveloppement dapplications informatiques. Il est donc absolument ncessaire de lintgrer notre cycle de dveloppement avec UML. Nous prsentons dans cette section une faon de spcier les cas de test avec UML.
Cas de test abstrait et interaction

Nous avons vu au chapitre prcdent quune interaction reprsentait une succession dchanges de messages entre plusieurs objets qui peuvent survenir pendant lexcution dune application. Il est possible de vrier quune interaction est ralise par lexcution dune application. Cela signie que la succession dchanges de messages spcie par linteraction a t ralise par lapplication lors de son excution. Dans le contexte du test, nous pouvons trs facilement faire un rapprochement entre les interactions et les cas de test. En effet, il est possible de considrer que la partie du cas de test qui concerne les stimuli envoys par le testeur vers lapplication est un change de
81
messages entre le testeur et des objets de lapplication. Cette partie du cas de test peut donc tre spcie grce une interaction. Pour pouvoir spcier intgralement un cas de test, il faut ds lors tre capable dajouter aux interactions la spcication des rsultats attendus, ainsi quune information prcisant que linteraction spcie un scnario initi par un objet externe lapplication (le testeur). Nous proposons donc de modier les classiques interactions UML an de pouvoir spcier des cas de test. Nous appellerons interaction de test une interaction respectant les contraintes suivantes : Linteraction doit obligatoirement contenir un objet reprsentant le testeur. Cet objet doit tre identi Testeur et ne pas avoir de type. Lobjet Testeur ne doit pas tre cr ni supprim par un objet de linteraction. Lobjet Testeur ne doit pas non plus recevoir de message dappel dopration. Linteraction doit obligatoirement contenir dautres objets. Tous les autres objets doivent tre identis et typs. Tous ces objets doivent tre crs par lobjet Testeur. Linteraction peut contenir des messages dappel dopration synchrone ou asynchrone, mais seul lobjet Testeur peut tre lobjet qui envoie ces messages. Linteraction doit contenir une note contenant le rsultat attendu. Nous appellerons diagramme de squence de test le diagramme de squence reprsentant graphiquement une interaction de test. Ce diagramme doit respecter les contraintes suivantes : Lobjet Testeur doit tre lobjet le plus gauche du diagramme. La note contenant le rsultat attendu doit apparatre sur le diagramme, de prfrence en bas, aprs le dernier message. La gure 7.2 prsente un diagramme de squence de test reprsentant un cas de test abstrait sur lalgorithme de tri que nous avons prsent prcdemment. Ce diagramme respecte toutes les contraintes que nous avons dnies. Soulignons que ce cas de test abstrait ne permet que de sassurer que lalgorithme ne retourne pas derreur de tri si nous lui demandons de trier le tableau b , a , c . Ce cas de test ne donne donc aucune garantie quant au rsultat du tri sur tout autre jeu de donnes. Soulignons que les interactions de test permettent de spcier les cas de test abstraits et non les cas de test concrets. En effet les interactions sont cohrentes avec les classes UML qui ne sont pas excutables car elles ne contiennent pas les traitements associs leurs oprations autrement que sous forme de note de code crite dans des langages de programmation tels que Java.
Cas de test excutables et interactions

Nous avons dj prcis quun cas de test excutable tait le reet dun cas de test abstrait an de permettre son excution sur lapplication. Dit autrement, un cas de test excutable est la traduction dun cas de test abstrait dans un langage de programmation particulier.
82
Figure 7.2
Cas de test abstrait en UML
Testeur cration t1:Tri
trier("b","a","c")
resultat attendu "a", " b", "c"
tant donn, dune part, que nous spcions les cas de test abstraits laide dinteractions cohrentes avec la partie structurelle du modle et que, dautre part, nous gnrons le code de lapplication grce lopration de gnration de code partir de cette partie structurelle, il semble naturel de vouloir gnrer les cas de test excutables laide dune opration de gnration de code de test similaire lopration de gnration de code que nous avons prsente au chapitre 5. Nous proposons donc de dnir une opration de gnration de code de test partir dune interaction. Ce code de test devant tre excut par un testeur, nous faisons le choix de ne pas dvelopper nous-mme ce testeur mais de rutiliser le framework de test JUnit (http://www.junit.org/index.htm). Celui-ci propose une API Java permettant de coder des cas de test et de les excuter sur une application Java. Notre opration de gnration de code de test partir dune interaction sappuie donc sur le framework JUnit et est spcie avec les rgles de correspondance suivantes : 1. toute interaction doit correspondre un cas de test JUnit. Cela signie quune nouvelle classe Java doit tre construite. Cette classe doit hriter de la classe JUnit TestCase. La classe doit contenir une mthode correspondant au test. Cette mthode aura pour nom testExecutable. 2. Dans la mthode testExecutable de la classe correspondant au cas de test, il doit correspondre un appel de mthode Java pour chaque message de linteraction partant de lobjet Testeur. Si le message est une cration, lappel de mthode Java doit tre une cration dobjet (new). Si le message est une suppression dobjet, nous considrons que la gnration sarrte en soulevant une erreur, car Java ne supporte pas les suppressions dobjets.
83
Si le message est un appel synchrone dopration, lappel de mthode Java doit tre un appel vers la mthode Java correspondant lopration. Si le message est un appel asynchrone dopration, nous considrons que la gnration sarrte en soulevant une erreur, car Java ne supporte pas nativement les appels asynchrones. 3. Dans la mthode testExecutable de la classe correspondant au cas de test, il doit correspondre une assertion JUnit correspondant au rsultat attendu spci dans linteraction. Pour pouvoir automatiser lcriture de cette assertion JUnit, il faut proposer un formalisme de spcication du rsultat attendu dans linteraction UML (notre exemple ne fait que spcier le rsultat attendu en langage naturel). UML ne standardise pas un tel formalisme, mais la plupart des outils UML proposent chacun leur propre formalisme de spcication. En appliquant ces rgles de gnration de code de test sur le cas de test abstrait que nous avons spci la section prcdente laide dune interaction, nous obtenons le cas de test excutable suivant :
public class TriInteraction extends TestCase { public void testExecutable() { t1 = new Tri() ; String[] resultatObtenu = t1.trier("b" , "a", "c") ; assertEquals(resultatObtenu[0] , "a") ; assertEquals(resultatObtenu[1] , "b") ; assertEquals(resultatObtenu[2] , "c") ; } }
Grce au framework JUnit, ce cas de test excutable peut tre excut sur lapplication qui aura t obtenue laide dune gnration de code.
84
Synthse
VUES Structure Comportement Fonctionnali t
ABSTRACTION
COHERENCE
Gnration de code et Reverse Engineering
Gnration de code de test
JUnit CODE
Excution des tests
Figure 7.3
TEST
Le test dans notre cycle de dveloppement avec UML
Nous avons introduit dans ce chapitre les concepts de base du test. Nous avons en particulier insist sur le principe fondamental du test, qui est de rvler les fautes de lapplication an de permettre lidentication des dfaillances. Il est important de souligner le fait que, si aucune faute nest rvle, cela ne donne aucune garantie sur la non-existence de dfaillances. Nous avons simplement identi un ensemble de donnes ne provoquant pas de dfaillance et navons aucune information sur ce qui se passe avec dautres donnes.
85
Nous avons ensuite prsent les concepts permettant la ralisation du test. Nous avons notamment dtaill les relations entre la spcication de lapplication, le code de lapplication, les cas de test abstraits et les cas de test excutables. Nous avons en outre montr en quoi les interactions UML et les diagrammes de squence pouvaient tre utiliss pour spcier les cas de test abstraits. Pour ce faire, nous avons propos une faon dutiliser les interactions an de permettre une spcication complte des cas de test. Pour nir, nous avons prsent une opration de gnration de code de test partir des interactions de test. Nous pouvons ds lors intgrer tous ces mcanismes dans notre cycle de dveloppement avec UML. La gure 7.3 schmatise cette intgration en mettant bien en vidence le fait que les parties structurelles et comportementales de bas niveau dabstraction sont exploites et offrent des gains de productivit pour le dveloppement de lapplication. En effet, si des fautes sont rvles aprs lexcution des tests sur lapplication, lidentication et la correction des dfaillances peuvent se faire soit sur le code, soit sur le modle.
TD7. Diagrammes de squence de test

La classe Partie de lapplication de gestion de championnat dchecs prsente au TD6 reprsente une partie dchecs. Elle permet aux joueurs de jouer leur partie en appelant lopration jouerCoup(). Chaque fois quun coup est jou, lopration vrifierMat() est appele an de vrier que la position nest pas mat. Si tel est le cas, la partie est nie. Aucun coup ne peut alors tre jou (voir TD6 pour la modlisation de classe Partie ainsi quun diagramme de squence spciant un cas nominal de droulement dune partie entre deux joueurs). Question 60. Identiez une faute qui pourrait intervenir lors du droulement dune partie. Question 61. Dnissez un cas de test abstrait visant rvler cette faute. Question 62. Construisez un diagramme de squence de test modlisant le cas de test abstrait de la question prcdente. Question 63. crivez le pseudo-code Java du cas de test excutable correspondant au cas de test abstrait de la question prcdente. Question 64. Si ce cas de test ne rvle pas de faute, est-ce que cela signie que lapplication ne contient pas de dfaillance ?
86
Question 65. Combien de cas de test faudrait-il laborer pour amliorer la qualit de lapplication ? Lapplication permettant la gestion de championnat dchecs contient aussi la classe ChampionnatDEchecs, qui est associe la classe Partie et qui permet de grer linscription des joueurs et la cration des parties (voir TD6). Question 66. Identiez une faute qui pourrait intervenir lors de la cration des parties dun championnat. Dnissez un cas de test abstrait visant rvler cette faute, et construisez un diagramme de squence de test modlisant ce cas de test abstrait. Question 67. Est-il possible de lier les deux cas de test abstrait que vous avez dnis (un la question 61, lautre la question 66) ? Ce TD aura atteint son objectif pdagogique si et seulement si : Vous savez identier des fautes possibles. Vous savez dnir les cas de test permettant de rvler les fautes. Vous avez conscience de la complexit de dnir un jeu de tests complet.
8
Plates-formes dexcution
Objectifs
I Dnir la notion de plate-forme dexcution I Prsenter la faon dont UML prend en charge les plates-formes I Prciser comment et pourquoi sabstraire des plates-formes dexcution
Java dans UML

Depuis le dbut de ce cours, tous les modles UML que nous avons prsents taient plus ou moins lis Java. Il est cependant essentiel de diffrencier, dans un modle UML, les lments qui dpendent de Java et les autres. Nous introduisons dans cette section les concepts de modle UML pour Java et de modle 100 % UML an dexpliciter cette diffrence.
Modles 100 % UML et modles UML pour Java

Lorsque nous avons prsent lopration de Reverse Engineering, nous avons expliqu, dune part, que les classes de lAPI Java taient introduites dans le modle et, dautre part, que le code Java tait intgr au modle dans des notes attaches aux oprations des classes. Lorsque nous avons prsent lopration de gnration de code, nous avons prcis des contraintes sur les modles. Ces contraintes ont t dnies an dassurer la gnration
88
du code Java. Elles dpendent donc de Java. Par exemple, nous avons prcis quil ne fallait pas que le modle UML utilise lhritage multiple, car celui-ci ntait pas support dans Java. Lorsque nous avons prsent les interactions, nous avons prcis des rgles assurant leur cohrence avec la partie structurelle du modle. De ce fait, elles dpendent aussi de Java. Il est notamment envisageable que des objets participant aux interactions soient des objets instances des classes de lAPI Java. Pour nir, lorsque nous avons prsent la gnration du code de test, nous avons utilis la plate-forme JUnit, qui est une plate-forme Java. Les interactions de tests sont donc elles aussi fortement dpendantes de Java. Pour rsumer, les modles que nous avons raliss depuis le dbut de ce cours sont des modles UML qui dpendent de Java. Nous les appelons modles UML pour Java . linverse, nous appelons modles 100 % UML les modles indpendants de tout langage de programmation.
UML productif ou prenne

Sil existe deux sortes de modles UML (modles 100 % UML et modles UML pour Java), il est important de bien comprendre ce qui les diffrencie et didentier les gains que nous pouvons obtenir de chacun dentre eux. Nous connaissons trs bien les modles UML pour Java, car ce sont les modles que nous avons utiliss depuis le dbut de ce cours. Comme indiqu la section prcdente, la particularit dun modle UML pour Java est de dpendre du langage de programmation Java. Cette particularit est autant un avantage quun inconvnient. Lavantage est que, grce cette dpendance, les oprations de gnration de code et de Reverse Engineering peuvent tre ralises conjointement, garantissant ainsi une synchronisation entre le modle et le code dune application. Grce cette synchronisation, il est possible dobtenir la fois les avantages des oprations ralisables sur les modles (recherche et modication des dpendances, gnration de documentation, spcication et gnration des cas de test en cohrence avec lapplication) et les avantages des oprations ralisables sur le code (codage, compilation et excution). Les modles UML pour Java offrent donc des gains de productivit vers le langage Java. Cette caractristique des modles UML pour Java est aussi un inconvnient, en ce quelle restreint les gains potentiels offerts par UML uniquement des gains de productivit vers le langage Java. Pour autant, UML a t dni historiquement an de faciliter la comprhension et la conception dapplications orientes objet. La majorit des concepts UML ont t dnis an de mieux apprhender la complexit de la construction de ces applications. Le concept dassociation, par exemple, est trs intressant pour spcier les liens structurels existant entre les classes. Ce concept permet typiquement de grer la complexit des applications mais noffre pas de gains de productivit pour gnrer le code de lapplication.
Plates-formes dexcution CHAPITRE 8
89
Les modles UML pour Java noffrent donc que peu de gains pour grer la complexit des applications orientes objet. Comme leur nom lindique, les modles 100 % UML sont quant eux compltement indpendants des plates-formes dexcution. Leurs avantages et inconvnients sont donc essentiellement inverses ceux des modles UML pour Java.
Plate-forme dexcution La notion de plate-forme dexcution englobe la fois les langages de programmation (Java, C++, C#, etc.) et les serveurs dapplications (J2EE, PHP, EJB, .Net, etc.).
Le fait que les modles soient indpendants des plates-formes dexcution fait que les informations quils contiennent sont, par dnition, indpendantes des changements internes des plates-formes. La plate-forme Java, par exemple, a dj chang cinq fois de version en dix ans, avec des modications assez importantes de lAPI, qui ncessitent une modication des modles UML pour Java dj raliss si lapplication modlise doit pourvoir sexcuter sur la nouvelle plate-forme. Faire un modle 100 % UML permet de saffranchir de ces modications et donc de rendre linformation beaucoup plus prenne. Faire un modle 100 % UML permet en outre, et surtout, de faire des choix de conception indpendamment des plates-formes dexcution. Il est ainsi possible de commencer un dveloppement sans avoir, au pralable, choisi la plate-forme dexcution. Pour nir, soulignons que la prennit de linformation contenue dans un modle 100 % UML est plus facile atteindre grce lemploi de tous les concepts UML construits spcialement pour cela (association, objet non typ, etc.). Rappelons que lobjectif premier dUML tait dtre un langage de modlisation, et non un langage de programmation. Linconvnient des modles 100 % UML est toutefois de navoir aucun lien avec les plates-formes dexcution. De ce fait, il est trs difcile de gnrer du code excutable partir dun modle 100 % UML. Si nous prenons lexemple de la plate-forme Java, que nous connaissons dj, il est trs difcile de gnrer du code partir dun modle 100 % UML utilisant lhritage multiple. Pour rsumer, les modles UML pour Java et les modles 100 % UML sont complmentaires. Les modles UML pour Java offrent des gains de productivit, tandis que les modles 100 % UML offrent des gains de prennit et facilitent la gestion de la complexit de la construction des applications orientes objet. Il est donc intressant de ne pas les considrer comme des modles indpendants, mais plutt comme des modles complmentaires.
90
Niveaux conceptuel et physique

Nous venons de voir que les modles 100 % UML et les modles UML pour Java taient complmentaires. En fait, les modles 100 % UML sont des abstractions des modles UML pour Java, car ils masquent toutes les informations relatives la plate-forme Java. Nous pourrions dire en outre que les modles UML pour Java prcisent les modles 100 % UML en expliquant comment utiliser la plate-forme Java pour mettre en uvre la conception exprime dans le modle 100 % UML.
Abstraction de la plate-forme
Comme les modles 100 % UML sont des abstractions des modles UML pour Java, il est possible de dnir une opration permettant de construire un modle 100 % UML partir dun modle UML pour Java. Il suft pour cela de supprimer toutes les informations relatives la plate-forme Java. Les rgles appliquer pour construire un modle 100 % UML partir dun modle UML pour Java sont les suivantes : 1. Supprimer toutes les associations entre les classes qui nappartiennent pas lAPI Java et les classes qui appartiennent lAPI Java. 2. Supprimer toutes les classes de lAPI Java. 3. Si une proprit dune classe qui nappartient pas lAPI Java a un type Java, remplacer ce type par un type UML correspondant (il peut tre ncessaire de dnir la classe reprsentant ce type sil ne sagit pas dun type UML de base). 4. Si une opration dune classe qui nappartient pas lAPI Java a un paramtre qui a un type Java, remplacer ce type par un type UML correspondant (mme remarque que pour les types des proprits). 5. Dans les interactions, supprimer les objets instances des classes de lAPI Java. Ces rgles draconiennes permettent dobtenir un modle 100 % UML partir dun modle UML pour Java. Cependant, il est important de noter que le modle 100 % UML obtenu nest pas rellement exploitable, car il ne contient que des informations partielles et incompltes. Il faut donc le complter en ajoutant des associations entres les classes ou en compltant les interactions an de bien spcier les informations principales de lapplication, aussi appeles informations mtier. Les informations relatives aux parties graphiques de lapplication, qui sont obligatoirement dpendantes de la plate-forme dexcution, sont, par exemple, entirement retires du modle 100 % UML. Le modle est ds lors indpendant des changements internes de la plate-forme Java et peut tre rutilis pour dautres ralisations (vers la plate-forme .Net, par exemple). linverse, il est trs dlicat de construire automatiquement un modle UML pour Java partir dun modle 100 % UML. En effet, si le modle 100 % UML utilise des constructions non supportes par la plate-forme Java, il faut traduire ces constructions an de
91
les reprsenter dans le modle UML pour Java. Par exemple, si le modle 100 % UML utilise lhritage multiple, il faut transformer tout hritage multiple en un ensemble dhritages simple, ce qui est possible mais reste une opration trs dlicate et trs complexe. De plus, construire automatiquement un modle UML pour Java partir dun modle 100 % UML ne peut se faire que si nous connaissons la signication des classes du modle 100 % UML an de bien identier la partie de lAPI Java utiliser. Par exemple, si nous savons que le modle 100 % UML dnit une classe responsable de la sauvegarde sur disque, nous pouvons utiliser lAPI Java ddie aux entres-sorties (java.io.File). Malheureusement, il nest pas possible de prciser ce niveau de dtail des classes en UML. Pour toutes ces raisons, plutt que de gnrer automatiquement des modles UML pour Java partir de modles 100 % UML ou linverse, nous prconisons plutt de spcier la logique mtier de lapplication laide dun modle 100 % UML et de spcier la ralisation de cette logique mtier sur une plate-forme dexcution particulire (pour nous Java) laide dun modle UML pour Java. Dnir la logique mtier dune application consiste, dune part, dnir les informations principales manipules par lapplication (objets mtier) et, dautre part, dnir les fonctions principales de lapplication (fonctions mtier) en prcisant leurs impacts en terme de modication sur les donnes. Lobjectif dun modle 100 % UML est donc de reprsenter la logique mtier de lapplication et non dexpliquer comment cela fonctionne dans Java. Tous les objets et fonctions dun modle 100 % UML ne se retrouvent donc pas obligatoirement tels quels dans le modle UML pour Java correspondant.
Niveaux dabstraction
Nous venons de voir que les modles 100 % UML et UML pour Java taient complmentaires, que les uns taient des abstractions des autres, et quil ntait pas envisageable de passer des uns aux autres laide doprations automatiques. De ce fait, il parait naturel de ne pas traiter ces modles comme des modles indpendants, mais plutt comme des parties dun mme modle situes diffrents niveaux dabstraction. Nous considrons les deux niveaux dabstraction suivants : Niveau conceptuel. Correspond au niveau 100 % UML. Ce niveau contient la logique mtier de lapplication, celle-ci tant spcie dune faon indpendante de toute plate-forme dexcution. Niveau physique. Correspond au niveau UML pour Java. Ce niveau contient la ralisation de la logique mtier sur une plate-forme dexcution particulire, les informations contenues ce niveau tant dpendantes de la plate-forme dexcution (Java dans notre cas).
92
Ces deux niveaux sont lis, car le niveau conceptuel est une abstraction du niveau physique. Plus prcisment, tous les lments du niveau conceptuel (classes, associations, interactions) doivent avoir au moins un lment correspondant dans le niveau physique. Par contre, tous les lments du niveau physique ne sont pas forcment des concrtisations dlments du niveau conceptuel, certains ayant pu tre ajouts pour obtenir un modle partir duquel il est possible de produire du code Java. Les liens entre ces niveaux ne sont pas obtenus par une opration de gnration automatique. Ils doivent tre prciss par le concepteur du modle lors de la conception du modle. Cette tche peut tre ardue. Elle nen est pas moins indispensable, car ces liens garantissent la cohrence des informations situes aux deux niveaux dabstraction.
Cycle de dveloppement UML

Notre cycle de dveloppement avec UML intgre maintenant deux niveaux dabstraction. Le niveau physique est en cohrence avec le code grce aux oprations de gnration de code et de Reverse Engineering. Le niveau conceptuel est en cohrence avec le niveau physique grce aux relations dabstraction spcies par le concepteur du modle. Dans cette section nous expliquons comment intgrer ces deux niveaux conceptuels dans notre cycle de dveloppement UML.
Intgration des deux niveaux dans le cycle

Nous venons de voir que les modles 100 % UML et les modles UML pour Java taient deux parties dun mme modle, situes deux niveaux dabstraction diffrents. Ces niveaux dabstraction correspondent aux deux niveaux dabstraction les plus bas de notre vision schmatique du modle UML dune application. La gure 8.1 illustre ces deux niveaux. Nous avons volontairement fait apparatre un lien de cohrence entre les parties structurelles des niveaux conceptuel et physique. Ce lien peut tre spci en UML laide dune relation dabstraction entre les classes situes dans ces deux niveaux. Cette relation dabstraction peut apparatre graphiquement sur un diagramme de classes laide dune che pointille. Par contre, nous navons pas fait apparatre de lien de cohrence entre les parties comportementales des deux niveaux. Cela sexplique par le fait quUML ne propose pas de concept permettant de reprsenter graphiquement une relation dabstraction entre deux interactions.
Approches possibles
Soulignons que les objectifs des niveaux physique et conceptuel sont complmentaires. Lintrt du niveau conceptuel par rapport au niveau physique est de prenniser les informations les plus importantes du modle (les informations mtier). De plus, en faisant abstraction des spcicits des plates-formes dexcution, la construction du niveau conceptuel permet de mieux apprhender la complexit de la construction des applica-

VUES
93
Structure
Comportement
Fonctionnalit
ABSTRACTION
COHERENCE Niveau conceptuel
Niveau physique
JUnit CODE
Excution des tests
TEST
Figure 8.1
Niveaux dabstraction physique et conceptuel dans le modle UML
tions orientes objet. Contrairement au niveau physique, le niveau conceptuel noffre donc pas de gain de productivit rellement quantiable. Cest pourquoi nous ne prconisons llaboration du niveau conceptuel que sil y a un rel intrt soit prenniser les informations mtier (si un changement de plate-forme dexcution est envisag), soit grer la complexit de lapplication en faisant abstraction des dtails techniques. Il est vrai que ces intrts se retrouvent principalement dans le contexte de la construction dapplications relativement complexes, dont la taille dpasse dix mille lignes de code. Pour les autres applications, dont la taille est infrieure dix mille lignes de code, lintrt de disposer dun niveau abstrait disparat devant la difcult mettre en uvre les relations de cohrence avec le niveau physique. Les deux approches envisageables pour suivre un cycle de dveloppement avec UML sont donc soit de mettre en uvre le niveau conceptuel, soit de sen passer. Il serait contre-productif de vouloir mettre absolument en uvre le niveau conceptuel si aucun bnce ne pouvait en tre retir.
94
Synthse
Nous avons vu dans ce chapitre que les modles que nous avons prsents jusquici taient fortement dpendants de la plate-forme Java. Forts de ce constat, nous avons introduit la notion de modle pour Java et de modle 100 % UML. Nous avons montr que les modles pour Java et les modles 100 % UML taient complmentaires et quils offraient des gains diffrents. Les modles pour Java apportent des gains de productivit, tandis que les modles 100 % UML apportent des gains de prennit et de gestion de la complexit. Nous avons ensuite prcis la relation dabstraction qui existait entre ces deux niveaux. Les modles 100 % UML sont des abstractions des modles UML pour Java, car ils masquent les dtails techniques de la plate-forme Java. Ainsi, les modles 100 % UML spcient la logique mtier de lapplication, alors que les modles UML pour Java spcient la faon dont est utilise la plate-forme Java pour raliser lapplication. Nous avons en outre expliqu pourquoi il tait plus naturel de considrer ces deux types de modles non pas comme des modles indpendants, mais comme des parties diffrentes dun mme modle, situes diffrents niveaux dabstraction. Nous avons alors prcis comment ces deux niveaux dabstraction (conceptuel et physique) taient intgrs notre vision schmatique des modles UML dapplications. Pour nir, nous avons introduit les deux faons envisageables de suivre un cycle de dveloppement avec UML, en prcisant quil ntait pas obligatoire de mettre en uvre le niveau conceptuel; tout dpendant des bnces que nous souhaitions obtenir du modle UML.
TD8. Plates-formes dexcution

Question 68. Le diagramme de lagence de voyage reprsent la gure 8.2 correspond-il un modle conceptuel ou un modle physique ? Question 69. Pensez-vous quil soit intressant dappliquer des patrons de conception sur les modles conceptuels ? Question 70. Le diagramme de squence reprsent la gure 8.3 est-il conceptuel ou physique ? Vous noterez quil fait intervenir une opration qui napparat pas dans le diagramme de classes initial. Quelle classe doit possder cette opration ?

Figure 8.2
95
Diagramme de lagence de voyage
Hotel -name:string
hotel 0..1
Reservation -dateArrivee:string -dateDepart:string +setHotel()
* reservationEffectuee
hotelPropose
AgenceDeVoyage +obtenirReservation() +demanderTarifs()
client:
ag:AgenceDeVoyage
obtenirReservation("Ritz","15juin","16juin") cration resa:Reservation addReservationEffectuee(resa)
ok
Figure 8.3
Interaction reprsentant une rservation
Question 71. Serait-il possible de spcier en 100 % UML le comportement de lagence de voyage ? Question 72. Serait-il possible de spcier en 100 % UML des tests pour lagence de voyage ? Justiez lintrt de ces tests. Question 73. Le diagramme reprsent la gure 8.4 est une concrtisation du diagramme conceptuel de lagence de voyage. Exprimez les relations dabstraction entre les lments des deux diagrammes.
96
Hotel -name:string
hotel 0..1
Reservation -dateArrivee:string -dateDepart:string
reservationEffectuee
0..1
ArrayList
AgenceDeVoyage +obtenirReservation() +demanderTarifs ()
0..1
hotelPropose
Iterator +next() +hasNext() Reservation res=null; for (Iterator it = reservationEffectuee.iterator() ; it.hasNext() ; ) { Reservation current = (Reservation) it.next(); if (current.dateArrivee == dateArrivee && current.dateDepart == dateDepart && current.hotel.name == hotelName) return current; } res = new Reservation(dateArrivee , dateDepart); res.setHotel(new Hotel( )); return res ; }
Figure 8.4
Classes du niveau physique de lagence de voyage
Question 74. Quel est lintrt davoir fait apparatre les classes ArrayList et Iterator dans le modle concret (considrez en particulier la gnration de code et le Reverse Engineering) ? Question 75. Construisez le diagramme de squence concrtisant le diagramme de squence prsent la question 69. Question 76. Exprimez les relations dabstraction entre les diagrammes de squence. Ce TD aura atteint son objectif pdagogique si et seulement si : Vous savez diffrencier des modles conceptuels et des modles physiques. Vous savez tablir des relations dabstraction entre modles de niveau diffrent. Vous avez conscience que plus le modle physique est proche de la plate-forme dexcution, plus il est loin du modle conceptuel (et inversement).
9
Diagrammes de cas dutilisation
Objectifs
I Prsenter les concepts UML relatifs la vue fonctionnelle (diagramme de cas dutilisation) I Prsenter la notation graphique du diagramme de cas dutilisation I Expliquer la smantique des cas dutilisation UML en prcisant le lien avec les
interactions UML
Vue fonctionnelle du modle UML

La partie fonctionnelle du modle UML dune application permet de spcier les fonctionnalits offertes par lapplication sans pour autant spcier la faon dont ces fonctionnalits sont ralises par les objets de lapplication.
Fonctionnalits dune application oriente objet

Le principe fondateur du paradigme objet est de runir en une seule et mme entit, lobjet, des donnes et des traitements. lpoque de la cration de ce paradigme, ce principe tait considr comme rvolutionnaire, car il allait rebours des paradigmes existants (fonctionnel et donnes), qui visaient sparer les donnes et les traitements dans des entits diffrentes.
98
Lavantage le plus important quapporte ce principe fondateur est de permettre lidentication, la dcomposition et la rutilisation dentits capables de raliser des traitements uniquement grce aux donnes quelles possdent. Avec le paradigme objet, il est possible de considrer une application comme un ensemble dobjets indpendants mais cohrents, chacun ralisant la tche pour laquelle il a t conu. Ainsi, si une tche ralise par un objet est ncessaire dans une autre application, il est possible de rutiliser lobjet. Linconvnient de ce principe fondateur est quil masque les fonctionnalits offertes par des groupes dobjets. En effet, leur spcication nest pas explicite et est rpartie dans les traitements et dans les interactions raliss par chacun des objets participant au groupe. De ce fait, il est trs difcile de spcier les besoins fonctionnels que nous avons sur une application laide dobjets. Ces besoins fonctionnels, qui sexpriment naturellement laide de fonctions, ne peuvent donc tre exprims simplement sous forme de groupes dobjets. Par exemple, si nous voulions spcier laide dobjets les besoins fonctionnels dune application de gestion de prts bancaires tels que la cration dun prt ou le calcul dun taux dintrt, il faudrait spcier lensemble des objets participant la ralisation de lapplication et spcier chacun des traitements associs ces objets. Si cela reste faisable, ce nest gure naturel pour nous dveloppeurs, plutt habitus utiliser le dcoupage fonctionnel. Pour rsoudre ce problme et rconcilier le paradigme objet avec la possibilit dexprimer les besoins dune application sous forme de fonctions, UML dnit le concept de cas dutilisation.
Concepts lmentaires
Cette section prsente les concepts lmentaires de la vue fonctionnelle dun modle UML. Dans notre contexte, ces concepts sont sufsants pour exprimer les fonctionnalits dune application.
Cas dutilisation
Smantique Un cas dutilisation spcie une fonction offerte par lapplication son environnement. Un cas dutilisation est spci uniquement par un intitul. Nous recommandons que lintitul du cas dutilisation respecte le pattern verbe + complments . Le verbe de lintitul permet de spcier la nature de la fonctionnalit offerte par lapplication, tandis que les complments permettent de spcier les donnes dentre ou de sortie de la fonctionnalit. Par exemple, le cas dutilisation calculer taux dintrt du prt permet de comprendre dune certaine manire que lapplication permet ses utilisateurs de calculer le taux dintrt dun prt.
Diagrammes de cas dutilisation CHAPITRE 9
99
Le concept de cas dutilisation offre une vue fonctionnelle sur lapplication. La faon dont sera ralis concrtement un cas dutilisation napparat pas dans la dnition du cas dutilisation. Elle sera prcise par la suite, lors de ltablissement des liens de cohrence avec les autres parties du modle. Graphique Un cas dutilisation se reprsente par une ellipse contenant lintitul du cas dutilisation. La gure 9.1 reprsente le cas dutilisation que nous avons introduit la section prcdente.
Figure 9.1
Reprsentation graphique dun cas dutilisation
Calculer taux d'intrt du prt
Acteur
Smantique Un acteur reprsente une entit appartenant lenvironnement de lapplication qui interagit avec lapplication. Le concept dacteur permet de classier les entits externes lapplication. Un acteur est identi par un nom. Graphique Un acteur se reprsente par un petit bonhomme et un nom (nom du rle). La gure 9.2 reprsente lacteur Client.
Figure 9.2
Reprsentation graphique dun acteur
Client
Systme
Smantique Un systme reprsente une application dans le modle UML. Il est identi par un nom et regroupe un ensemble de cas dutilisation qui correspondent aux fonctionnalits offertes par lapplication son environnement. Lenvironnement est spci sous forme dacteurs lis aux cas dutilisation.
100
Graphique Un systme se reprsente par un rectangle contenant le nom du systme et les cas dutilisation de lapplication. Les acteurs, extrieurs au systme, sont reprsents et relis aux cas dutilisation qui les concernent. Lensemble correspond un diagramme de cas dutilisation. La gure 9.3 reprsente le diagramme de cas dutilisation dune application de gestion de prts bancaires avec son unique cas dutilisation offert lacteur qui reprsente le client.
Figure 9.3
Diagramme de cas dutilisation
Gestion de prts bancaires
Calculer taux d'intrt du prt
Client
Liens avec les autres parties du modle

Nous venons de voir que la partie fonctionnelle du modle UML permettait de spcier les fonctionnalits dune application mais aussi de prciser quelles entits externes ces fonctionnalits sont offertes. Il est possible dlaborer plusieurs diagrammes de cas dutilisation chaque niveau dabstraction permettant de regrouper les fonctionnalits de lapplication en diffrents sous-systmes. Cependant, nous considrons dans ce cours quil suft dlaborer un unique diagramme de cas dutilisation par niveau dabstraction. Ce diagramme reprsente les fonctionnalits principales de lapplication un niveau dabstraction donn et les principaux bnciaires de ces fonctionnalits. Il correspond en quelque sorte lemballage commercial des applications vendues en grande surface, sur lequel sont crites les fonctionnalits offertes par lapplication ses utilisateurs. Nous savons que les fonctionnalits dune application oriente objet sont ralises par les objets qui composent lapplication. Ces objets sont spcis laide des classes prsentes dans la partie structurelle du modle de lapplication, alors que les fonctionnalits sont spcies dans la partie fonctionnelle du modle. Il est donc ncessaire de faire apparatre un lien de cohrence entre les parties structurelle et fonctionnelle du modle UML an de savoir quels sont les objets ralisant telle ou telle fonctionnalit. Pour tablir ce lien entre les parties structurelle et fonctionnelle du modle UML, nous prconisons dutiliser les interactions prsentes dans la partie comportementale du
101
modle de lapplication. Lide sous-jacente est de faire correspondre chaque cas dutilisation une ou plusieurs interactions spciant un exemple de ralisation de la fonctionnalit. Ainsi, les cas dutilisation sont en cohrence avec les interactions, lesquelles sont en cohrence avec les classes, puisque les objets qui apparaissent dans les interactions sont typs par des classes spcies dans la partie structurelle du modle. Plus prcisment, nous prconisons de raliser pour chaque cas dutilisation : au moins une interaction spciant lexcution normale de lapplication ; une interaction spciant les excutions soulevant des erreurs de lapplication. La gure 9.4 illustre les relations de cohrence entre les parties fonctionnelle, comportementale et structurelle du modle dune application. Nous constatons que les cas dutilisation du diagramme de cas dutilisation sont relis des diagrammes de squence et que les objets de ces diagrammes de squence sont relis des classes. Par rapport notre vision schmatique du modle UML dune application, ces liens entre les vues fonctionnelle, comportementale et structurelle existent chacun des niveaux dabstraction du modle. Nous verrons au chapitre 10 de ce cours comment mettre en uvre les relations de cohrence entre les diffrents niveaux dabstraction. Dans chacune de ces interactions, nous prconisons de faire apparatre les objets correspondant aux acteurs qui utilisent la fonctionnalit. Il est dailleurs possible de faire en sorte que le type dun objet participant une interaction soit un acteur (et non une classe). An damliorer la visibilit des diagrammes de squence reprsentant ces interactions, nous prconisons de faire apparatre les objets reprsentant des acteurs gauche du diagramme. De plus, nous prconisons de rutiliser, autant que possible, les mmes objets dans toutes les interactions spcies. Cela donne une meilleure visibilit au modle en ne multipliant pas inutilement le nombre des objets. Notons quil est possible dexploiter ces interactions an de dnir des interactions de test (voir le chapitre 7), ce que nous ne ferons pas dans le cadre de ce cours.
Concepts avancs
Les concepts avancs que nous prsentons dans cette section permettent de spcier plus nement les fonctionnalits et lenvironnement dune application. Ces concepts sont toutefois si dlicats employer que nous dconseillons fortement leur utilisation. Nous ne les prsentons quan de complter notre prsentation du diagramme de cas dutilisation. Soulignons en outre que ces concepts nont quasiment pas volu entre les versions UML 1.4 et UML 2.1.
Concepts avancs relatifs aux cas dutilisation

Cette section prsente les concepts avancs applicables aux cas dutilisation. Ces concepts sont essentiellement des relations entre cas.
102
Systme
CasUtilisation1
CasUtilisation2 Acteur1
Vue fonctionnelle
Objet2 Objet2 Objet2
Objet1
Objet2 Objet2 Objet2
Objet1
Objet1 Message1 Objet1 Message1 Message2 Message1 Message2 Message2
Objet1 Message1 Objet1 Message1 Message2 Message1 Message2 Message2
Vue comportementale
Classe1 1 *
Classe2
Classe3
Vue structurelle
Figure 9.4
Liens de cohrence entre les vues dun modle
include
Smantique Il est possible de spcier quun cas dutilisation inclut un autre cas dutilisation. tant donn que les cas dutilisation correspondent des fonctions, la relation dinclusion entre deux cas dutilisation peut tre compare une relation dinclusion de fonctions. En dautres termes, si un cas dutilisation C2 hrite dun cas dutilisation C1, lexcution de C1 fait appel C2.
103
La relation dinclusion entre cas dutilisation doit cependant tre employe avec parcimonie. Lidal est de ny recourir que lorsquun cas dutilisation est inclus dans au moins trois ou quatre autres cas, car cela permet de factoriser le cas inclus. Soulignons le fait que la relation dinclusion ne doit pas tre utilise pour exprimer une dcomposition fonctionnelle entre plusieurs cas. En effet, la relation dinclusion ne permet pas de prciser une quelconque relation dordre ou de priorit dappel entre les cas inclus. Graphique La relation dinclusion entre cas dutilisation se reprsente graphiquement laide dune che pointille sur laquelle nous faisons apparatre la chane de caractres include . La che va du cas qui inclut vers le cas inclus. La gure 9.5 reprsente une relation dinclusion entre deux cas dutilisation.
Figure 9.5
Relation dinclusion entre cas dutilisation
include
extend
Smantique Il est possible de spcier quun cas dutilisation tend un autre cas dutilisation. Cela signie en quelque sorte quun comportement qui ntait pas spci est ajout au cas tendu. La relation dextension est souvent utilise pour prciser des fonctionnalits optionnelles qui sont ajoutes aux fonctionnalits de base. Graphique La relation dextension entre cas dutilisation se reprsente graphiquement laide dune che pointille sur laquelle nous faisons apparatre la chane de caractres extend . La che va du cas qui tend vers le cas tendu. La gure 9.6 reprsente une relation dextension entre deux cas dutilisation.
Figure 9.6
Relation dextension entre cas dutilisation
extends
104
Hritage
Smantique Il est possible de spcier une relation dhritage entre cas dutilisation. Si un cas dutilisation C1 hrite dun cas dutilisation C2, C2 peut tre substitu C1 pour un acteur qui souhaite bncier de C1. Cette smantique reste toutefois ambigu, car les conditions de substitution ne sont pas spcies. Cest pourquoi nous dconseillons vivement lutilisation de cette relation. Graphique Comme lhritage entre classes, la relation dhritage entre cas dutilisation se reprsente graphiquement par une che allant du cas dutilisation qui hrite vers le cas dutilisation hrit. La gure 9.7 reprsente une relation dhritage entre deux cas dutilisation.
Figure 9.7
Relation dhritage entre cas dutilisation
Concept avanc relatif aux acteurs

Cette section prsente un concept avanc applicable aux acteurs. Nous choisissons ici de ne prsenter que la relation dhritage, car cette relation est employe dans certains diagrammes.
Hritage
Smantique Il est possible dexprimer une relation dhritage entre deux acteurs. La signication de cette relation dhritage est sensiblement la mme que celle de la relation dhritage entre classes (voir le chapitre 2). Si un acteur A1 hrite dun acteur A2, cela signie que toutes les entits externes correspondant A1 correspondent aussi A2. Il est important de souligner que cette relation est ensembliste (tous les A1 sont des A2). De ce fait, elle ne doit pas tre employe si nous voulons exprimer quune entit externe peut correspondre deux acteurs diffrents. Par exemple, si les acteurs Client et Caissier ont t dnis et que nous voulions exprimer quun caissier peut tre un client, il ne faut surtout pas utiliser la relation dhritage.
105
Graphique Comme la relation dhritage entre classes, la relation dhritage entre acteurs se reprsente par une che allant de lacteur qui hrite vers lacteur hrit. La gure 9.8 reprsente une relation dhritage entre lacteur ClientPrivilgi et lacteur Client.
Figure 9.8
Relation dhritage entre acteurs
Client
ClientPrivilgi
Synthse
Nous avons dtaill dans ce chapitre la partie fonctionnelle dun modle UML. Cette partie permet de reprsenter les diffrentes fonctionnalits offertes par lapplication son environnement. Il sagit de la dernire des trois parties du modle UML que nous voulions introduire dans ce cours. Il est important de rappeler que si UML propose dautres parties, nous avons choisi de ne pas les prsenter an de nous concentrer sur les parties indispensables la mise en uvre dun cycle de dveloppement avec UML tel que nous le concevons. Nous avons ensuite prsent les liens de cohrence qui existent entre les parties fonctionnelle, comportementale et structurelle. Ces liens de cohrence ajouts aux oprations de synchronisation avec le code permettent dobtenir la fois les gains des oprations de modlisation tous les niveaux dabstraction et les gains des oprations ralisables sur le code. Cest ce que nous cherchions obtenir ds le dbut de ce cours. Pour nir, nous avons introduit les concepts avancs de la partie fonctionnelle dun modle UML, en insistant bien sur le fait que ces concepts tant trs dlicats employer, il ne fallait y recourir quen cas de relle ncessit. Le prochain et dernier chapitre de ce cours sintresse un moyen mthodologique permettant de comprendre un peu mieux comment mettre en place un cycle de dveloppement UML.
106
TD9. Diagrammes de cas dutilisation

Le diagramme de cas dutilisation de la gure 9.9 reprsente les fonctionnalits dune agence de voyage classique.
Agence De Voyage
Raliser Devis
include
Annuler Reservation
Client
Rserver Voyage
include include
Donner Cheque
Payer Voyage
extend
Faire un voyage
extend
Donner CD Payer sur le web Voyageur
Figure 9.9
Diagramme de cas dutilisation de lagence de voyage
Question 77. Commentez les acteurs du diagramme de cas dutilisation. Question 78. Commentez les cas dutilisation du diagramme de cas dutilisation. Nous souhaitons raliser le diagramme de cas dutilisation du championnat dchecs prsent au TD6. Donnez la liste des acteurs du systme. Donnez la liste des cas dutilisation du systme en les liant aux acteurs. Donnez le diagramme de cas dutilisation du systme. Reprenez les diagrammes de squence raliss au TD6 pour lapplication de championnat dchecs, et expliquez comment les relier au diagramme de cas dutilisation obtenu la question prcdente.
Question 79. Question 80. Question 81. Question 82.
Ce TD aura atteint son objectif pdagogique si et seulement si : Vous arrivez diffrencier les fonctionnalits de base dune application et son organisation fonctionnelle (diffrence entre les niveaux besoin et conceptuel).
107
Vous savez tablir un diagramme de cas dutilisation dune application partir de la description textuelle de cette dernire. Vous savez faire le lien entre un diagramme de cas dutilisation et les diagrammes de squence dune application au niveau besoin.
10
Dveloppement avec UML
Objectifs
I Prsenter les principes dun support mthodologique I Proposer une mthodologie simple de support au dveloppement avec UML I Illustrer lintrt dUML pour le dveloppement
Analyse et conception
Nous avons dj indiqu au chapitre 1 que la nalit de lactivit de dveloppement tait de fournir une solution informatique un problme pos par un utilisateur, aussi appel client. Nous avons prcis que le code ntait que la matrialisation de la solution, tandis que le modle contenait toutes les informations facilitant dune manire ou dune autre la construction de la solution. Aprs cette introduction aux vues essentielles dun modle UML (structurelle, comportementale et fonctionnelle) dune application, il nous reste prsenter la faon dont nous devons utiliser chacune de ces parties an de raliser notre objectif : la ralisation de la solution partir du problme. Pour atteindre cet objectif, lingnierie logicielle a identi depuis plusieurs annes deux phases principales raliser : lanalyse du problme et la conception de la solution.
110
Analyse du problme
La phase danalyse sert modliser la comprhension du problme pos par le client. Cette phase sert aussi bien dnir les contours de lapplication. Grce la phase danalyse, nous savons ce qui doit tre intgr dans la solution, mais aussi ce qui ne doit pas ltre, puisque la solution ne doit prendre en compte que ce qui a t identi lors de lanalyse. Idalement, une analyse doit tre ralise par lquipe de dveloppement et valide par le client, lequel certie ainsi que lquipe de dveloppement a bien compris son problme. Dans ce cours, nous considrons que le problme du client est spci dans un cahier des charges. Le cahier des charges est un document textuel fourni par le client, mais qui nest pas intgr dans le modle dune application. Dans notre contexte, la phase danalyse consiste modliser tous les besoins prsents dans le cahier des charges. Une analyse est complte lorsque lintgralit du problme est modlise de manire non ambigu. Pour modliser un cahier des charges avec UML, nous considrons que seules deux parties du modle UML sont intressantes, les parties fonctionnelle et structurelle : La partie fonctionnelle permet de spcier les fonctionnalits ralises par lapplication (cas dutilisation) ainsi que les contours de lapplication (acteurs). La partie structurelle permet de spcier sous forme dobjets les donnes que doit manipuler lapplication. Ces deux parties du modle UML sont sufsantes pour modliser les besoins du client exprims dans le cahier des charges. Cependant, an de bien prciser les liens de cohrence entre ces deux parties, nous utilisons aussi la partie comportementale, comme nous lavons montr au chapitre prcdent. Cette partie permet en effet de lier les cas dutilisation aux interactions; elles-mmes lies aux classes. Dans le cadre de notre vision schmatique du modle UML dune application, nous considrons que la phase danalyse correspond un niveau dabstraction que nous appelons le niveau besoin.
Conception de la solution
La phase de conception consiste modliser une solution qui rsout le problme modlis dans la phase danalyse. Contrairement ce que nous pourrions croire, fournir une solution informatique nest pas ce quil y a de plus difcile : cest juste un problme algorithmique. Par contre, il est bien plus compliqu de fournir la meilleure solution au problme, car, un problme donn, correspondent bien souvent plusieurs solutions. Prenons lexemple du tri. Il existe plusieurs faons de trier des lments (tri itratif, tri bulles, tri rapide, etc.). Toutes ces solutions rsolvent le problme du tri dun point de vue
Dveloppement avec UML CHAPITRE 10
111
algorithmique, mais elles ne sont pas toutes quivalentes, et nous savons trs bien que certaines sont meilleures que dautres. Pour diffrencier les solutions, deux critres sont bien connus : la complexit en espace et la complexit en temps. Ces critres permettent dtablir un classement des solutions en fonction de la place mmoire quelles occupent et du temps quelles mettent raliser le traitement. Dautres critres, plus adapts au monde industriel et au paradigme objet, permettent deffectuer dautres classements des solutions. Citons notamment la maintenabilit, la portabilit, la robustesse, la rapidit de dveloppement, le cot de dveloppement, etc. Cette liste non exhaustive de critres montre que la construction dune solution optimale est loin dtre triviale. Pour tre pragmatique, mais aussi pour simplier la difcult de la phase de conception, nous considrons dans le cadre de ce cours quune conception optimale est une conception qui maximise lindpendance lgard des plates-formes techniques et minimise les dpendances entre les diffrents objets de lapplication. ces deux objectifs, nous faisons naturellement correspondre les deux niveaux dabstraction que nous avons introduits au chapitre 8. En effet, nous avons vu que le niveau conceptuel permettait de dnir une conception indpendante des plates-formes dexcution. Nous avons vu en outre au chapitre 4 quil tait possible de minimiser les relations de dpendance entre les packages du niveau physique.
Comment passer du quoi au comment ?

De manire intrinsque, lanalyse et la conception sont fondamentalement diffrentes, la premire correspondant la modlisation du problme, et la seconde la modlisation de la solution. Il existe entre ces deux niveaux une relation de rsolution, puisque la conception rsout lanalyse. Il est important de souligner quil ne sagit pas l dune relation dabstraction telle quelle existe entre les niveaux dabstraction conceptuel et physique. La solution (dnie par la conception) nest pas la concrtisation dun problme (dni par lanalyse) sur une plate-forme particulire. Il existe une relle diffrence entre le problme et la solution. Cest dailleurs l o le travail du dveloppeur prend tout son sens : fournir la meilleure solution susceptible de rponde au problme. Pour autant, le fait que lanalyse et la conception tirent parti du paradigme objet et que la solution soit, par dnition, la solution du problme rendent quelque peut confuse cette diffrence pourtant fondamentale. En effet, le modle danalyse contient des classes, lesquelles dnissent la structure et le comportement des objets du problme. Or, il nest pas rare de trouver dans la solution des classes aux structures et aux comportements relativement voisins. Prenons lexemple dune application de gestion de prts bancaires. Le modle danalyse dnit la classe Prt. Cette classe dnit la structure et le comportement des prts tels
112
que perus dans le problme. Cette classe permet, par exemple, de renseigner le montant du prt ainsi que son taux. Or, il est parier que la solution exploite elle aussi la classe Prt et que cette classe ressemble fortement la classe appartenant au problme. Pour autant, cette relation troite tablie entre les classes danalyse et les classes de conception ne doit pas faire oublier que ces deux phases ont des objectifs fondamentalement diffrents. An de faciliter le passage de la phase danalyse la phase de conception, nous prconisons didentier au niveau conceptuel les gros composants de lapplication. Un gros composant, reprsent laide dun package, est une entit relativement autonome, responsable dune partie des traitements ncessaires au bon droulement de lapplication. titre dexemple, nous pouvons mentionner, pour lapplication de gestion de prts bancaires, un composant responsable des traitements graphiques de lapplication (afchage des rsultats, prsentation des formulaires de saisie, etc.), un composant responsable de la sauvegarde des prts sur disque dur (sauvegarde sur chier, chargement partir dun chier, etc.) et un composant responsable du calcul des taux et de la validation de lacceptation du prt. Chaque composant joue un rle spcique dans lapplication, et lensemble des composants est responsable de toutes les fonctionnalits de lapplication (exprimes dans la phase danalyse). La dcoupe en composants dune application est une opration dlicate, qui reste la charge du dveloppeur. Cest l que rside la relation de rsolution entre le niveau analyse et le niveau conception. Dans le modle UML de lapplication, les composants sont spcis au niveau conceptuel. Chaque composant est spci par une partie fonctionnelle, qui reprsente les fonctionnalits du composant offertes son environnement, une partie comportementale, qui reprsente des exemples de ralisation des fonctionnalits du composant, et une partie structurelle, qui reprsente les classes du composant. De plus, toujours au niveau conceptuel, mais de faon transverse tous les composants, la partie structurelle du modle spcie les relations de dpendance entre les composants. Celles-ci sont exprimes sous forme de dpendance entre les packages reprsentant les composants. UML ne proposant aucun concept pour spcier une relation de rsolution entre les niveaux besoin et conceptuel, nous prconisons dutiliser des notes de commentaires intgres dans le niveau conceptuel. Chaque note de commentaires, attache un lment de nimporte quel type (classe, association, objet, message, cas dutilisation, acteur, etc.), doit identier les lments du niveau besoin spciant le problme en partie rsolu. Nous prconisons de prciser les relations de rsolution pour chaque composant du niveau conceptuel. Plus prcisment, nous prconisons, dune part, dattacher aux cas dutilisation de chaque composant une note ciblant les cas dutilisation du niveau besoin que le compo-
113
sant rsout et, dautre part, dattacher aux classes ou aux packages de chaque composant une note ciblant les classes du niveau besoin que le composant rsout. La gure 10.1 illustre ces relations de rsolution entre le niveau besoin et le niveau conceptuel. La gure fait apparatre deux gros composants dans le niveau conceptuel. Chacun de ces gros composants est spci laide dun diagramme de cas dutilisation, dun ensemble de diagrammes de squence et dun diagramme de classes. Les relations de rsolution sont schmatises laide de ches entre les niveaux besoin et conceptuel.
Niveau besoin
Niveau conceptuel
Figure 10.1
Relation de rsolution entre le niveau besoin et le niveau conceptuel
En rsum, selon notre vision schmatique du modle UML dune application, nous considrons que : Lanalyse correspond un niveau dabstraction besoin . La conception correspond deux niveaux dabstraction : le niveau conceptuel et le niveau physique. Le niveau conceptuel spcie les diffrents composants de lapplication. Le niveau physique spcie la faon dont ces composants sont raliss sur la plate-forme technique (Java dans notre cas). Il existe des relations de rsolution entre le niveau besoin et le niveau conceptuel. Ces relations sont exprimes laide de commentaires dans le niveau conceptuel.
114
Il existe des relations dabstraction entre le niveau conceptuel et le niveau physique. Ces relations sont exprimes laide de la relation dabstraction entre les classes (voir le chapitre 8). Grce ces relations entre toutes les parties du modle UML et les phases danalyse et de conception, nous pouvons complter notre vision schmatique dun cycle de dveloppement avec UML comme illustr la gure 10.2.
VUES
Structure
Comportement
Fonctionnalit
ANALYSE
Niveau besoin
ABSTRACTION
COHERENCE Niveau conceptuel
Niveau physique
CONCEPTION JUnit CODE

Excution des tests
TEST
Figure 10.2
Cycle de dveloppement avec UML (version complte)
Mthode de dveloppement
Comme expliqu au chapitre 1, une mthode de dveloppement doit rpondre aux questions suivantes : Quand raliser une activit ? Qui doit raliser une activit ? Quoi faire dans une activit ? Comment raliser une activit ?
115
Maintenant que nous avons prsent toutes les parties du modle UML dune application, nous savons ce que propose UML pour rpondre aux questions du quoi et du comment. Nous pouvons ds lors proposer une rponse relativement minimaliste aux questions du quand et du qui et, ainsi, proposer une mthode de dveloppement avec UML. Notre objectif est de nir notre prsentation dUML en prsentant les principes de base dune mthode de dveloppement. Notre mthode ne doit donc pas tre considre comme une relle mthode, applicable en milieu industriel, mais plutt comme une mthode pdagogique. Pour rpondre la question du qui, nous considrons quil existe essentiellement deux personnes qui participent au dveloppement dune application. Le client est la personne qui a besoin de lapplication, et le dveloppeur la personne qui ralise lapplication. Dans le cadre de ce cours, nous considrons que lquipe de dveloppement nest compose que de dveloppeurs. Ainsi, la rdaction du cahier des charges, qui spcie tous les besoins, est la charge du client, et toutes les activits de dveloppement relatives lanalyse et la conception sont la charge de lquipe de dveloppement. Pour rpondre la question du quand, nous considrons quil suft de proposer un ordre de ralisation de chacune des neuf parties du modle UML. Nous faisons le choix de proposer un ordre partant du cahier des charges et nissant par la production de lapplication nale. Ainsi, notre mthode, qui se borne prconiser un parcours dans la ralisation des parties du modle, est une mthode dite top-down . Cela signie quelle nest utilisable que pour la construction de nouvelles applications. Les gains de notre mthode de dveloppement avec UML sont, comme nous lavons soulign tout au long de ce cours, de proter des avantages des oprations ralisables sur les modles (gnration de documentation, gnration de tests, identication et correction des dpendances), de proter des avantages des oprations ralisables sur le code (rdaction du code, compilation et excution), de permettre une conception indpendante des plates-formes dexcution et minimisant les dpendances entre les composants.
La mthode UML pour le dveloppeur

Nous rcapitulons dans cette section toutes les tapes de notre mthode de dveloppement avec UML. Soulignons que les tapes 1 9 concernent llaboration des neuf parties du modle UML. 0. Rdaction du cahier des charges : Objectif : spcier tous les besoins du client sur lapplication. Quand : cette tape doit tre ralise avant de commencer le dveloppement. Elle nappartient donc pas rellement la mthode. Qui : le client. Quoi : un document textuel recensant tous les besoins. Lidal serait de pouvoir identier chacun des besoins (en leur donnant un numro, par exemple).
116
Comment : nous ne prconisons aucune faon de rdiger un cahier des charges, cela sortant du contexte de ce cours. 1. Analyse (niveau besoin) cas dutilisation : Objectif : modliser les fonctionnalits de lapplication et lenvironnement de lapplication de manire non ambigu. Quand : cette tape est la premire de notre mthode. Qui : lquipe de dveloppement. Quoi : lunique diagramme de cas dutilisation du niveau dabstraction besoin . Comment : laide dune lecture soigneuse du cahier des charges, il faut, dune part, identier les fonctionnalits offertes par lapplication an de les modliser sous forme de cas dutilisation et, dautre part, identier les entits externes lapplication bnciant des fonctionnalits de lapplication an de les modliser sous forme dacteurs. Rappelons que nous dconseillons lutilisation de relations dinclusion, dextension et dhritage entre les cas dutilisation ainsi que les relations dhritage entre acteurs. 2. Analyse (niveau besoin) interaction : Objectif : modliser les exemples de ralisation des fonctionnalits de lapplication de manire non ambigu. Quand : cette tape doit tre ralise aprs ltape 1. Il est possible de raliser ltape 3 en mme temps que cette tape. Analyse classe et analyse interaction peuvent tre faites ensemble. Qui : lquipe de dveloppement. Quoi : un diagramme de squence, par exemple nominal de ralisation dune fonctionnalit et un diagramme de squence, par exemple de ralisation dune fonctionnalit soulevant une erreur. Comment : laide dune lecture soigneuse du cahier des charges, il faut modliser des exemples de ralisation des fonctionnalits. Nous conseillons de rutiliser autant que possible de mmes objets dans les diffrentes interactions. An dtablir un lien de cohrence entre les parties fonctionnelle, comportementale et structurelle, nous conseillons de typer tous les objets participant aux interactions, soit par des acteurs (partie fonctionnelle), soit par des classes (partie structurelle). 3. Analyse (niveau besoin) classes : Objectif : modliser les classes reprsentant les donnes spcies dans le cahier des charges. Quand : cette tape doit tre ralise aprs ltape 1 et peut tre faite en mme temps que ltape 2. Analyse classe et analyse interaction peuvent tre faites ensemble. Qui : lquipe de dveloppement.
117
Quoi : autant de diagrammes de classes que ncessaire an de faciliter la lecture des classes ainsi que leurs relations. Comment : laide dune lecture soigneuse du cahier des charges, il faut modliser les donnes spcies par le cahier des charges. Nous conseillons de ne pas rendre les associations navigables, car les informations que nous pourrions en retirer (dpendances entre objets) ne sont pas du ressort de la phase danalyse. 4. Conception (niveau conceptuel) cas dutilisation : Objectif : modliser les composants de la conception de lapplication. Quand : cette tape, la quatrime de notre mthode, est la premire de conception. Elle doit tre ralise aprs toutes les tapes de la phase danalyse. Qui : lquipe de dveloppement. Quoi : liste des composants et un diagramme de cas dutilisation par composant. Comment : laide dune lecture soigneuse de toutes les parties de la phase danalyse, il faut identier les diffrents composants de lapplication puis laborer le diagramme de cas dutilisation de chacun des composants. Il faut ensuite spcier les relations de rsolution entre les diagrammes de cas dutilisation des composants et le diagramme de cas dutilisation de la phase danalyse. 5. Conception (niveau conceptuel) interaction : Objectif : modliser les exemples de ralisation des fonctionnalits de chacun des composants de lapplication. Quand : cette tape est la deuxime de la phase de conception. Il est possible de raliser ltape 7 en mme temps que cette tape. Qui : lquipe de dveloppement. Quoi : un diagramme de squence, par exemple nominal de ralisation dune fonctionnalit. Un diagramme de squence, par exemple de ralisation dune fonctionnalit soulevant une erreur. Comment : partir de la dnition des composants, il faut laborer des exemples de ralisation des fonctionnalits quils proposent. Nous conseillons de rutiliser autant que possible de mmes objets dans les diffrentes interactions. An dtablir un lien de cohrence entre les parties fonctionnelle, comportementale et structurelle, nous conseillons de typer tous les objets participant aux interactions, soit par des acteurs (partie fonctionnelle), soit par des classes (partie structurelle). 6. Conception (niveau conceptuel) classes : Objectif : modliser les classes des composants. Toutes les classes dun mme composant doivent appartenir un mme package. Quand : cette tape, la troisime de conception de notre mthode, doit tre ralise aprs ou en mme temps que ltape 5. Qui : lquipe de dveloppement.
118
Quoi : autant de diagrammes de classes que ncessaire an de faciliter la lecture des classes ainsi que leurs relations. Comment : partir de la dnition des composants, il faut modliser les donnes quils manipulent. Il faut prciser les relations de dpendance entre les classes (intracomposants et inter-composants). Objectif : modliser les classes des composants en intgrant les classes de la plateforme dexcution. 7. Conception (niveau physique) classes : Quand : cette tape est la premire de la phase de conception du niveau physique de notre mthode. Qui : lquipe de dveloppement. Quoi : autant de diagrammes de classes que ncessaire an de faciliter la lecture des classes ainsi que leurs relations. Comment : partir de la spcication des composants (partie structurelle du niveau conceptuel), il faut identier les classes de la plate-forme dexcution permettant la concrtisation des composants. Il faut aussi intgrer les traitements associs aux oprations sous forme de note de code. Pour nir, il faut prciser les relations dabstraction avec le niveau conceptuel. 8. Conception (niveau physique) interaction : Objectif : modliser les cas de test abstraits. Quand : cette tape est la deuxime de la phase de conception du niveau physique. Qui : lquipe de dveloppement. Quoi : un diagramme de squence de test par cas de test abstrait. Comment : pour chaque classe du niveau conceptuel, il faut identier plusieurs tests abstraits raliser et modliser ces cas de test laide de diagrammes de squence de test. Comme indiqu au chapitre 7, notre mthode ne donne aucun moyen didentier les bons cas de test. 9. Conception (niveau physique) cas dutilisation : Objectif : modliser les fonctionnalits offertes par les composants, mais au niveau physique. Quand : cette tape est la troisime de la phase de conception du niveau physique. Qui : lquipe de dveloppement. Quoi : un diagramme de cas dutilisation par package du niveau physique. Comment : en principe, tous les composants du niveau conceptuel apparaissent dans le niveau physique sous forme de packages. Certaines fonctionnalits des composants du niveau conceptuel peuvent toutefois tre offertes directement par la plateforme dexcution. La modlisation des fonctionnalits au niveau physique permet
119
ainsi de diffrencier les fonctionnalits directement ralises par lapplication de celles offertes par la plate-forme. 10. Gnration du code et des tests : Objectif : gnrer le code de lapplication et celui des tests. Quand : cette tape est la premire de la phase de codage. Qui : lquipe de dveloppement. Quoi : le code de lapplication et celui des tests. Comment : en excutant les oprations de gnration de code et de tests.
VUES
Structure
Comportement
Fonctionnalit
ANALYSE
3
ABSTRACTION
2
COHERENCE
Niveau besoin
Niveau conceptuel
Niveau physique
10 11
CONCEPTION
JUnit
TEST
CODE
Excution des tests
Figure 10.3
tapes de la mthode et parties du modle UML
11. Compilation et excution du code et des tests : Objectif : compiler et excuter le code de lapplication et celui des tests.
120
Quand : cette tape est la deuxime de la phase de codage. Qui : lquipe de dveloppement. Quoi : lexcutable. Comment : en excutant les oprations de compilation et dexcution fournies par la plate-forme dexcution. 12. Modication de lapplication (correction de bogues ou ralisation dvolutions) : Objectif : mettre jour lapplication. Quand : tout moment aprs ltape 11. Qui : lquipe de dveloppement. Quoi : modication du modle ou du code. Comment : en modiant nimporte quelle partie du modle ou en modiant le code. Les oprations de gnration de code et de Reverse Engineering doivent tre utilises pour assurer la synchronisation entre le code et le modle. Toutes ces tapes, aprs la rdaction du cahier des charges, se retrouvent dans notre vision schmatique du modle UML dune application, telle quillustre la gure 10.3.
Synthse
Dans ce chapitre, qui clt ce cours, nous avons prsent la faon dont sarticulent toutes les parties du modle UML dune application lors de la ralisation dun dveloppement avec UML. Nous avons en particulier soulign la distinction entre les phases danalyse et de conception, qui permettent respectivement de spcier le problme pos par le client et la solution propose par lquipe de dveloppement. Nous avons en outre propos une mthode pdagogique permettant de suivre un cycle de dveloppement avec UML lors de la construction dune nouvelle application. Ce cycle prconise un chemin dans llaboration de toutes les parties du modle UML et se termine par la gnration de code. Grce cette mthode mais surtout grce aux diffrentes parties du modle labores en UML, il est possible de cumuler les avantages de la modlisation avec ceux du codage. Insistons nouveau sur le fait que la mthode que nous avons prsente nutilise pas de manire exhaustive toutes les possibilits dUML ni toutes les oprations applicables sur les modles (simulation de modles, vrication de proprits, etc.), qui permettent dobtenir dautres gains. Cependant, notre mthode prsente les parties dun modle UML qui offrent le plus davantages en terme de dveloppement et quil est ncessaire de matriser pour pouvoir aller plus loin dans la modlisation des systmes.
121
TD10. Dveloppement avec UML

Une association dornithologie vous cone la ralisation du systme logiciel de recueil et de gestion des observations ralises par ses adhrents (le logiciel DataBirds). Lobjectif est de centraliser toutes les donnes dobservation arrivant par diffrents canaux au sein dune mme base de donnes, qui permettra ensuite dtablir des cartes de prsence des diffrentes espces sur le territoire gr par lassociation. Les donnes renseigner pour chaque observation sont les suivantes : Nom de lespce concerne. Il y a environ trois cents espces possibles sur le territoire en question. Si lobservation concerne plusieurs espces, renseigner plusieurs observations Nombre dindividus. Lieu de lobservation. Date de lobservation. Heure de lobservation. Conditions mto lors de lobservation. Nom de chaque observateur. Quelle que soit la faon dont sont collectes les donnes, celles-ci sont saisies dans la base dans un tat dit valider . Tant que les donnes ne sont pas valides par les salaris de lassociation, des modications peuvent tre faites sur les donnes. La validation des donnes se fait uniquement par les salaris de lassociation qui ont le droit de modier la base de DataBirds. Ils doivent vrier que les donnes saisies sont cohrentes. Plus prcisment, ils doivent valider les noms des observateurs (les noms doivent correspondre des noms dadhrents) et lespce (celle-ci doit correspondre une espce connue sur le territoire). Aprs validation, une saisie se trouve soit dans ltat dit valid , soit dans ltat dit non valid . Les saisies dans ltat non valid sont automatiquement purges de la base une fois par semaine. Grce aux donnes saisies et valides, lassociation souhaite pouvoir tablir diffrents types de cartes de prsence des diffrentes espces : Cartes gographiques par espce prsentant un cumul historique des populations. Ce traitement peut tre demand par un adhrent. Cartes des observations ralises par chaque observateur. Ce traitement peut tre demand par un salari uniquement. Ces cartes de prsence des oiseaux sont gnres par DataBirds et accessibles soit par le Web, soit par demande via un courrier lectronique ou postal. Question 83 Effectuez la premire tape de la mthode. Question 84 Effectuez la deuxime tape de la mthode (niveau besoin - comportement).
122
Question 85 Effectuez la troisime tape de la mthode. Question 86 Effectuez la quatrime tape de la mthode. Question 87 Effectuez la cinquime tape de la mthode. Question 88 Effectuez la sixime tape de la mthode. Question 89 Effectuez la septime tape de la mthode. Question 90 Effectuez la huitime tape de la mthode sur une seule classe. Question 91 Effectuez la neuvime tape de la mthode. Ce TD aura atteint son objectif pdagogique si et seulement si : Vous savez appliquer chaque tape de la mthode. Vous comprenez limportance des relations de cohrence entre les parties du modle. Vous tes capable de mesurer les gains offerts grce llaboration du modle UML dune application.
11
Corrigs des TD
TD1. Un curieux besoin de modlisation
partir du code donn en annexe, rpondez aux questions suivantes. 1. En une phrase, quels sont les rles de chacune des classes ?
Voici la liste des classes et leur rle : Repertoire reprsente le rpertoire (dans lapplication il ny en a quun). Personne reprsente une che dune personne dans le rpertoire. Adress reprsente une adresse postale. UIRepertoire correspond la reprsentation graphique dun rpertoire partir de laquelle les actions sur le rpertoire pourront tre appeles. UIPersonne correspond la reprsentation graphique dune che dune personne partir de laquelle les actions sur la che dune personne pourront tre appeles. UIMenuActionListener reprsente la classe charge de capter tous les clics destins interagir avec un rpertoire et dappeler les traitements associs. La classe anonyme dnie dans la classe UIPersonne est charge de capter tous les clics destins interagir avec la che dune personne et dappeler les traitements associs. MyAssistant est la classe qui contient la fonction principale (le main) de lapplication. Elle cre linterface associe au rpertoire gr par lapplication.
2. Peut-on dire quil existe des classes reprsentant des donnes et des classes reprsentant des interfaces graphiques ? Si oui, pourquoi et quelles sont ces classes ?
Toutes les classes commenant par UI sont graphiques. Les classes UIRepertoire et UIPersonne reprsentent les interfaces graphiques permettant la gestion des rper-
124
toires et des personnes, tandis que la classe UIMenuActionListener est en charge de la gestion des actions sur les interfaces et de la ralisation des fonctionnalits associes ces actions. Les classes Repertoire, Personne et Adresse reprsentent les donnes manipules par lapplication. La classe MyAssistant ne reprsente ni des donnes ni des interfaces graphiques ; elle sert lancer lapplication.
3. Est-il possible que le numro de tlphone dune personne soit +33 1 44 27 00 00 ?
Oui, parce que les proprits telephoneMaison, telephonePortable et telephoneBureau de la classe Personne sont de type string et quaucune vrication nest faite sur sa valeur.
4. Est-il possible que ladresse e-mail dune personne soit je_ne_veux_pas_donner_mon_email ?
Oui, parce que la proprit mail de la classe Personne (qui correspond ladresse email) est de type string et quaucune vrication nest faite sur sa valeur.
5. Quelles sont les fonctionnalits proposes par les menus graphiques de cette application ?
Il faut regarder les classes grant les interfaces graphiques. Elles crent, dans notre cas, soit des menus droulants, soit des boutons de soumission. La classe UIRepertoire cre trois menus droulants : Fichier, Organisation et Aide. Les fonctionnalits sont les lments de chacun de ces trois menus. Mis part le nom de ces fonctionnalits, le code de cette classe ne permet pas de connatre le service ralis par chacune de ces fonctionnalits. Voici chacun des menus avec les lments quil contient : Menu Fichier : Nouveau Ouvrir Enregistrer Enregistrer Sous Menu Organisation : Ajouter Nouvelle Personne Rechercher Personne(s) Menu Aide : A Propos La classe UIPersonne est linterface graphique associe une personne. Elle cre deux boutons de soumission : Save et Cancel. Comme pour les menus droulants, seul le nom des boutons peut nous renseigner sur la fonctionnalit associe.
6. Quelles sont les fonctionnalits rellement ralises par cette application ?
Pour avoir la rponse, il faut regarder dans le code associ aux classes de gestion des interfaces.
Corrigs des TD CHAPITRE 11
125
Pour un rpertoire, il sagit de la classe UIMenuActionListener, dans le code de laquelle nous constatons que seules les fonctionnalits Ajouter Nouvelle Personne et Nouveau sont ralises. Les autres fonctionnalits ne font quafcher un message. Pour une personne, il ny a pas de classe nomme associe la gestion de linterface. Il faut regarder, dans le code de la classe UIPersonne, le code associ la classe anonyme assurant la gestion de linterface. Nous constatons alors que les fonctionnalits Save et Cancel sont ralises.
7. Est-il possible de sauvegarder un rpertoire dans un chier ?
Cest a priori possible puisque loption Enregistrer Sous du menu Fichier le laisse supposer. Cependant, le code nous informe que cette fonctionnalit nest pas encore ralise.
8. Si vous aviez rdiger un document dcrivant tout ce que vous savez sur cette application an quil puisse tre lu par un dveloppeur qui veut rutiliser cette application et un chef de projet qui souhaite savoir sil peut intgrer cette application, quelles devraient tre les caractristiques de votre document ?
Le document doit contenir toutes les informations relatives aux diffrentes vues (diversit), aux diffrents niveaux dabstraction sans oublier les relations de cohrence reliant tous ces lments. Plus prcisment, partir du code de lapplication, il est possible (mais pas simple) de rdiger une documentation : des services offerts par lapplication (utile au dveloppeur et au chef de projet) ; de conception de lapplication (utile au dveloppeur) ; darchitecture de lapplication (utile au dveloppeur) ; des logiciels ncessaires lutilisation de lapplication (utile au dveloppeur et au chef de projet).
9. Rdigez un document prsentant lapplication MyAssistant.
Lapplication MyAssistant permet de grer des rpertoires. Un rpertoire contient des informations relatives des personnes. Pour chaque personne, il est possible de stocker un nom, un prnom, un numro de tlphone du domicile, un numro de tlphone du travail, un numro de tlphone de portable, un numro de fax, un titre, une socit, une adresse et une adresse e-mail.
10. Rdigez un document dcrivant les fonctionnalits de lapplication MyAssistant.
Attention : linterprtation des fonctionnalits non ralises par le code Java fourni se fait en fonction du nom du menu associ et par similitude ce qui se fait dans la majorit des applications. Les fonctionnalits offertes par lapplication sont de deux sortes. Les fonctionnalits sur un rpertoire et les fonctionnalits sur une personne.
126
Les fonctionnalits de gestion dun rpertoire sont les suivantes : Crer un nouveau rpertoire (menu Fichier/Nouveau). Ouvrir un rpertoire dj existant (menu Fichier/Ouvrir). Enregistrer un rpertoire, cest--dire enregistrer toutes les informations sur les personnes identies dans le rpertoire (menu Fichier/Enregistrer). Lenregistrement se fait dans le chier dorigine du rpertoire sil sagit du rpertoire dj existant. Sinon, lenregistrement se fait dans un nouveau chier que lutilisateur aura identier. Enregistrer un rpertoire dans un autre chier que le chier dorigine, sil existe (menu Fichier/Enregistrer Sous). Ajouter une nouvelle personne dans le rpertoire ouvert (menu Organisation/ Ajouter Nouvelle Personne). Cette fonctionnalit propose lutilisateur de saisir les informations correspondant une nouvelle personne. Rechercher une personne (menu Organisation/Rechercher Personne). Cette fonctionnalit permet de rechercher la totalit des informations sur une personne en nen saisissant quune partie (nom, numro de tlphone, une partie du nom, etc.). Il faudrait avoir le cahier des charges ou un code complet pour savoir exactement partir de quoi la recherche peut tre faite. Afcher laide sur lapplication (menu Aide/A Propos). Cette fonctionnalit permet lutilisateur daccder laide disponible sur lapplication. L aussi, il ny a aucune information sur la forme de cette aide. Les fonctionnalits de gestion dune personne sont les suivantes : Sauvegarder les informations saisies pour une personne (bouton Save de linterface graphique associe une personne). Attention : pour ajouter effectivement une personne un rpertoire, il faut enregistrer le rpertoire. Se contenter de sauvegarder les informations relatives la personne nest pas sufsant. Annuler les modications faites sur les informations dune personne (bouton Cancel de linterface graphique associe une personne). Cette fonctionnalit annule toutes les modications faites depuis la dernire sauvegarde des informations.
11. Rdigez un document dcrivant larchitecture gnrale de lapplication MyAssistant.
Une solution (qui nest pas unique) consiste considrer un composant pour : linterface graphique ; la base de donnes stockant les informations sur les personnes et les rpertoires ; linterface avec la base de donnes ; la ralisation de la logique des fonctionnalits de lapplication. La gure 1 illustre les liens de communication qui existent entre les diffrents composants. Il est important de donner la lgende du schma.
127
Interface graphique
Logique Fonctionnalits
Interface base de donnes
Composant graphique Composant logique Composant base de donnes Communication

Figure 1
Base de donnes des personnes et rpertoires
Architecture gnrale de MyAssistant
TD2. Diagrammes de classes

12. Dnissez la classe UML reprsentant un tudiant, caractris, entre autres, par un identiant, un nom, un prnom et une date de naissance.
Voici une solution ne prenant en compte que les proprits dun tudiant nommes dans la question. La classe se nomme Etudiant, et elle possde les quatre proprits suivantes, reprsentes la gure 2 : id, de type Integer, qui reprsente lidentiant de ltudiant. nom, de type String, qui reprsente le nom de ltudiant. prenom, de type String, qui reprsente le prnom de ltudiant. dateNaissance, de type String, qui reprsente la date de naissance de ltudiant.
Figure 2 Classe Etudiant
Etudiant id:integer nom:string prenom:string dateNaissance:string
128
Cette dnition nimpose aucune rgle sur le format de saisie de la date de naissance.
13. Dnissez la classe UML reprsentant un enseignant, caractris, entre autres, par un identiant, un nom, un prnom et une date de naissance.
La rponse est similaire celle de la question prcdente, si ce nest que le nom de la classe est maintenant Enseignant, comme lillustre la gure 3.
Figure 3
Classe Enseignant
Enseignant id:integer nom:string prenom:string dateNaissance:string
14. Dnissez la classe UML reprsentant un cours, caractris par un identiant, un nom, le nombre dheures de cours magistral, le nombre dheures de travaux dirigs et un nombre dheures de travaux pratiques que doit suivre un tudiant.
La question tant exhaustive sur les proprits de la classe, il ny a pas de choix. Les seules liberts sont sur les types des proprits. Voici une solution possible. La classe se nomme Cours, et elle possde les cinq proprits suivantes (voir gure 4) : id, de type integer, qui reprsente lidentiant du cours. nom, de type string, qui reprsente le nom du cours. nbHeuresCours, de type integer, qui reprsente le nombre dheures de cours magistral. nbHeuresTD, de type integer, qui reprsente le nombre dheures de travaux dirigs. nbHeuresTP, de type integer, qui reprsente le nombre dheures de travaux pratiques.
Figure 4
Classe Cours
Cours id:integer nom:string nbHeureCours:integer nbHeureTD:integer nbHeureTP:integer
15. Dnissez les associations qui peuvent exister entre un enseignant et un cours.
La question nest pas assez prcise pour quune seule solution soit possible. Toutes les associations ralistes sont possibles. Nous considrons deux associations entre ces classes. La relation Responsabilit permet dassocier un cours lenseignant qui en est responsable et dassocier un
129
enseignant lensemble des cours quil gre (un enseignant pouvant ne grer aucun cours). La relation Dispenser permet dassocier un cours lensemble des enseignants qui y participent (nous parlons alors des intervenants dun cours), cet ensemble ne devant pas tre vide. Cette relation permet aussi dassocier un enseignant lensemble des cours quil dispense, ensemble qui lui non plus ne peut tre vide. Les associations reprsentes la gure 5 prennent en compte toutes les contraintes prcdentes.
Cours id:integer nom:string nbHeureCours:integer nbHeureTD:integer nbHeureTP:integer 1..* coursDispense coursGere * Dispenser 1..* intervenant responsable 1 Enseignant id:integer nom:string prenom:string prenom:string dateNaissance:string
Responsabilite
Figure 5
Associations entre les classes Cours et Enseignant
Nous ne nous sommes pas intresss la navigabilit des associations. Cependant, mme si les associations ne sont pas navigables, des liens peuvent tre crs entre objets instances des classes. Dans ce cas, les objets seront lis mais nauront pas connaissance des liens. Il ne sera, par exemple, pas possible de passer par un cours pour accder son responsable. La faon dont les choses seront rellement ralises dpend de la plate-forme dexcution utilise.
16. Dnissez la classe UML reprsentant un groupe dtudiants en utilisant les associations.
Il nest pas possible dutiliser une association groupe de la classe Etudiant vers ellemme. Cette association permettrait de relier des tudiants entre eux mais ne permettrait pas didentier les diffrents groupes. Il est donc ncessaire davoir une reprsentation nous permettant didentier les groupes. Nous ajoutons donc une classe Groupe, que nous associons la classe Etudiant. Lassociation entre les deux classes se nomme Groupement. Nous considrons quun tudiant peut appartenir plusieurs groupes, voire aucun, quun groupe contient au moins deux membres mais na pas de limite suprieure sur le nombre de ses membres. Lassociation est graphiquement reprsente la gure 6.
Etudiant groupe Groupe * 2..* Groupement membre id:integer nom:string prenom:string dateNaissance:string
Figure 6
Classe Groupe
130
17. Dnissez lassociation possible entre un groupe dtudiants et un cours.
Nous nommons lassociation GroupeDeCours. Nous considrons que les groupes sont rednis pour chaque cours et quil faut au moins un groupe pour quun cours ait lieu. En consquence, un groupe nous nassocions quun seul cours, et un cours nous associons un plusieurs groupes. La gure 7 reprsente graphiquement lassociation GroupeDeCours.
Figure 7
Association GroupeDeCours
Groupe 1..* groupeExistant
GroupeDeCours cours 1
18. Pensez-vous quil soit possible de dnir un lien dhritage entre les classes UML reprsentant respectivement les tudiants et les enseignants ?
Pour pouvoir dnir un lien dhritage entre deux classes, il faut que lensemble des objets instances dune des deux classes soit inclus dans lensemble des objets instances de lautre. Ce nest pas le cas ici, puisque tous les tudiants ne sont pas des enseignants et que tous les enseignants ne sont pas des tudiants. Le fait que des enseignants puissent aussi tudier certains cours ne peut se reprsenter avec un lien dhritage entre classes. Le lien entre ces deux classes dobjets est quils partagent certaines proprits propres une personne. Si nous voulons faire apparatre ce lien, il nous faut introduire une classe Personne, comme le montre la gure 8. Les classes Etudiant et Enseignant hritent alors de la classe Personne.
19. Pensez-vous quil soit possible de dnir un lien dhritage entre les classes UML reprsentant respectivement les tudiants et les groupes dtudiants ?
Ce nest pas possible pour la mme raison que prcdemment. Les classes Etudiant et Groupe reprsentent des ensembles dobjets diffrents ne prsentant aucune relation dinclusion. Les groupes ne sont pas des tudiants (et inversement). Par contre, les groupes sont composs dtudiants, et les tudiants appartiennent des groupes, ce qui est reprsent par lassociation Groupement.

Figure 8
131
Hritage pour les classes Etudiant et Enseignant
Personne id:integer nom:string prenom:string prenom:string dateNaissance:string
Etudiant id:integer nom:string prenom:string dateNaissance:string
Enseignant id:integer nom:string prenom:string prenom:string dateNaissance:string
20. On nomme coursDeLEtudiant() lopration permettant dobtenir lensemble des cours suivis par un tudiant. Positionnez cette opration dans une classe, puis prcisez les paramtres de cette opration, ainsi que les modications apporter aux associations pralablement identies pour que votre solution soit ralisable.
Il semble assez naturel de mettre cette opration dans la classe Etudiant, car les associations permettent, partir dun tudiant, de retrouver lensemble des cours auxquels il assiste. Dans ce cas, les paramtres dentre (in) sont inexistants, et lopration sapplique sur lobjet courant (ltudiant). Le type du retour de lopration est un ensemble, ventuellement vide, de cours de type Cours. Pour mettre en place cette solution, il est indispensable de pouvoir accder aux groupes auxquels un tudiant appartient et, depuis ces groupes, de pouvoir accder au cours associ chacun deux. Il faut alors mettre les navigabilits adquates sur lassociation Groupement de la classe Etudiant vers la classe Groupe et sur lassociation GroupeDeCours de la classe Groupe vers la classe Cours. Si nous acceptons dajouter des associations par rapport ce qui a dj t fait, une solution pour mettre en place notre solution est de dnir une association entre les classes Etudiant et Cours permettant dassocier directement un tudiant aux cours quil suit et un cours aux tudiants qui le suivent. Cette association doit tre navigable de la classe Etudiant vers la classe Cours.
21. Nous nommons coursDeLEnseignant() lopration permettant dobtenir lensemble des cours dans lesquels intervient un enseignant. Positionnez cette opration dans une classe, puis prcisez les paramtres de cette opration, ainsi que les modications apporter aux associations pralablement identies an que votre solution soit ralisable.
132
Il semble assez naturel de mettre cette opration dans la classe Enseignant, car les associations permettent, partir dun enseignant, de retrouver lensemble des cours dans lesquels il intervient. Dans ce cas, les paramtres dentre (in) sont inexistants, et lopration sapplique sur lobjet courant (lenseignant). Le type du retour de lopration est un ensemble, ventuellement vide, de cours de type Cours. Pour mettre en place cette solution, il est indispensable de pouvoir accder aux cours que dispense un enseignant. Il faut donc mettre les navigabilits adquates sur lassociation Dispenser de la classe Enseignant vers la classe Cours.
22. Expliquez le diagramme de classes reprsent la gure 9.
Figure 9
Diagramme de classes du package planning
planning
Planning
Semaine numro:integer occupe calculerCreneauxLibres() *
5 * Salle numro:integer salle salle 1
joursOuvrables
Jours date:string nom:string ferie() calculerCreneauxLibres() 1 jours
crneaux
Le diagramme de classes du package planning reprsente loccupation dun ensemble de salles (ventuellement vide).
133
Ce package contient cinq classes, Planning, Salle, Semaine, Jours et Creneau. La classe Creneau contient les informations dun crneau horaire dtermin par une heure de dbut et une heure de n. Un crneau est associ un jour. Il permet didentier un crneau doccupation dune salle un jour donn. La classe Jours contient les informations sur lensemble de crneaux occups de ce jour. Un jour est dtermin par une date et un nom (jour dans la semaine). Il est possible de savoir si un jour correspond un jour fri et quels sont ses crneaux libres. Cette dernire opration est possible grce lassociation navigable entre les classes Jours et Creneau, qui permet davoir la liste des crneaux occups pour un jour donn. Cette classe permet donc didentier les crneaux doccupation dune salle pour un jour donn. La classe Semaine contient les informations sur les crneaux composant lensemble des jours de la semaine. Une semaine est reprsente par son numro. Lassociation navigable de la classe Semaine vers la classe Jours permet davoir accs aux informations sur les crneaux occups de lensemble des jours de la semaine. Cette association est ncessaire pour la ralisation de lopration calculerCreneauxLibres(), qui permet didentier les crneaux libres pour une semaine donne. Nous avons en plus linformation quune Semaine est compose de cinq jours ouvrables exactement. Cette classe permet donc didentier les crneaux doccupation dune salle pour une semaine donne. La classe Salle contient les informations sur loccupation dune salle. Une salle est reprsente par son numro. Lassociation navigable entre la classe Salle et la classe Semaine permet de rcuprer lensemble des informations sur loccupation de la salle pour un nombre quelconque de semaines. Une semaine est associe une seule salle. Une mme semaine (en terme de numro) existera en autant dexemplaires que de salles occupes cette mme semaine. Chacune de ces semaines reprsente loccupation dune salle en particulier. Cette classe permet donc didentier les crneaux doccupation dune salle pour un ensemble de semaines. La classe Planning contient les informations sur loccupation dun ensemble de salles (ventuellement vide). Elle ne contient aucune proprit. Grce une association vers la classe Salle, il est possible daccder lensemble des salles et de rcuprer les informations sur leur occupation.
23. Positionnez toutes vos classes (Etudiant, Enseignant, Cours, GroupeEtudiant) dans un package nomm personnel.
La solution est donne par la gure 10.

24. Liez vos classes an de faire en sorte quun crneau soit li un cours !
Il faut mettre une association entre la classe Cours du package personnel et la classe Creneau du package planning. Si nous souhaitons pourvoir identier le cours ayant lieu dans une salle pour un jour et un crneau donns, il faut que cette association soit navigable de la classe Creneau vers la classe Cours et que le package planning importe le package personnel. Cest ce quillustre la gure 11.
134
personnel
Enseignant id:integer nom:string prenom:string prenom:string dateNaissance:string
1..*
Dispenser
1..*
intervenant 1 responsable
coursDispense * Responsabilite coursGere
cours
GroupeDeCours
1..* Etudiant id:integer nom:string prenom:string dateNaissance:string * Groupement 2..*
groupeExistant
Groupe
groupe
membre
Figure 10
Package personnel

Figure 11
135
Packages planning et personnel
planning
Planning occupe *
Semain numro:integer calculerCreneauxLibres() 5 joursOuvrables
Jours date:string nom:string ferie() calculerCreneauxLibres() 1 * jours crneaux
* Salle
salle
salle 1
numro:integer
creneau
personnel
1 Enseignant id:integer nom:string prenom:string prenom:string dateNaissance:string 1..* Dispenser 1..*
coursAssoci Cour
intervenant coursDispense 1 * Responsabilite responsable coursGere
id:integer nom:string nbHeureCours :integer nbHeureTD:integer nbHeureTP:integer
1 cours GroupeDeCours
1..* Etudiant id:integer nom:string prenom:string dateNaissance:string * groupe Groupement 2..* membre
groupeExistant
Groupe
136
TD3. Reverse Engineering

Les oprations de Reverse Engineering prsentes dans ce TD portent sur le code Java de lapplication MyAssistant donn au TD1. Nous appliquons les rgles de correspondance Java vers UML dcrites au chapitre 3. 25. Effectuez le Reverse Engineering de la classe Adresse.
Les informations se trouvent dans le code de la classe Adresse : Rgle 1 : la classe Java Adresse doit correspondre une classe UML Adresse. Rgle 3 : tout attribut de la classe Java Adresse doit correspondre une proprit de mme nom dans la classe UML associe. Le type Java de tous les attributs de la classe Adresse tant string, le type des proprits associes sera le type UML string. Il y a cinq proprits : pays, region, codePostal, ville et rue. Rgle 4 : toute opration de la classe Java Adresse doit correspondre une opration de mme nom appartenant la classe UML correspondante. La classe Java Adresse contient deux oprations. Il sagit des oprations de lecture de la valeur dun attribut (public typeAttribut getNomAttribut()) et des oprations daffectation dune valeur un attribut (public void setNomAttribut(typeAttribut nomParamtre)). Nous retrouvons donc les oprations quivalentes dans la classe UML. Les oprations de lecture dun attribut sont traduites par une opration ayant un paramtre de sortie du type de lattribut et aucun paramtre dentre (getNomAttribut():typeAttribut). Les oprations daffectation dune valeur un attribut sont traduites par une opration avec un paramtre dentre du mme type que lattribut et aucun paramtre de sortie (setNomAttribut(In nomParamtre:typeAttribut). Les oprations Java tant toutes publiques, les oprations UML correspondantes le seront toutes aussi. Seules ces trois rgles sappliquent au Reverse Engineering de la classe Adresse. Il ne faut pas oublier dattacher chacune des oprations une note contenant le code de traitement de lopration Java associe (rgle 9). Dans la reprsentation graphique de la classe qui est donne la gure 12, les oprations sont prcdes dun +, et leur paramtres sont masqus. Nous avons aussi choisi de masquer les notes attaches aux oprations.
Figure 12
Classe Adresse
Adresse -pays:string -region:string -codePostal:string -ville:string -rue:string +getCodePostal() +setCodePostal() +getPays() +setPays() +getRegion() +setRegion() +getRue() +setRue() +getVille() +setVille()
137
26. Effectuez le Reverse Engineering de la classe Personne.
Les informations se trouvent dans le code de la classe Personne. La traduction de la majorit des attributs et oprations Java ne pose pas de problme particulier et se fait de faon similaire ce que nous avons fait pour la classe Adresse. Pour les oprations, la seule diffrence vient de lopration toString(), qui ne modie pas un attribut ni ne retourne sa valeur. Elle retourne en fait une chane de caractres compose de la valeur de deux attributs. Sa traduction ne pose pas de problme particulier : nous ajoutons la classe Personne du modle UML lopration +toString():string. Il ne faut pas oublier dattacher chacune des oprations une note contenant le code de traitement de lopration Java associe. Pour les attributs, la seule diffrence vient de lattribut adresse de type Adresse. Nous appliquons alors la rgle 3 modie, qui nous dit de ne pas crer de proprit Adresse mais de crer une association navigable entre la classe Personne et la classe Adresse. Le nom de rle associ la classe Adresse est le mme que celui de lattribut Java. Il sagit donc ici de adresse. Une personne ayant une seule adresse, nous prcisons sur lassociation UML qu une Personne est associe 0 1 adresse (nous acceptons davoir une proprit dont la valeur nest pas dnie). La gure 13 reprsente lassociation entre les classes Personne et Adresse.
Figure 13
adresse Personne 0..1 Adresse
Association entre les classes Personne et Adresse
27. Effectuez le Reverse Engineering de la classe Repertoire.
Les informations se trouvent dans le code de la classe Repertoire. Cette classe ne possde quun attribut de type ArrayList, qui est une classe Java. Comme pour la question prcdente, nous appliquons la rgle 3 modie. Nous ne crons donc pas de proprit dans la classe Repertoire mais crons une classe UML ArrayList et une association navigable entre les classes UML Repertoire et ArrayList. Le nom de rle associ la classe ArrayList est le nom de lattribut Java, ici personnes, et la multiplicit associe cette classe est 0..1. La classe Java contient cinq oprations, dont nous retrouvons les oprations correspondantes dans la classe UML Repertoire. Il ne faut pas oublier dajouter pour chacune delles une note contenant le code Java. Voici la liste de ces oprations :
+ajouterPersonne(in p:Personne) +supprimerPersonne(in p:Personne) +rechercherPersonnesParNome(in nom:string): +listerPersonnes():Personnes[*] +Repertoire():Personnes[*]
Les deux dernires oprations retournent un tableau de personnes dont la taille nest pas prcise.
138
La gure 14 reprsente lassociation entre les classes Repertoire et ArrayList.

Figure 14
personnes Repertoire 0..1 ArrayList
Association entre les classes Repertoire et ArrayList
28. Pourquoi ny a-t-il pas dassociation entre la classe Repertoire et la classe Personne alors quun rpertoire contient des personnes ?
La dclaration des attributs de la classe Java Repertoire ne mentionne aucun attribut de type Personne, mais mentionne un attribut de type ArrayList. Le lien entre le rpertoire et les personnes se fait grce au lien qui existe entre les classes Java ArrayList et Personne. Ces classes sont lies par la classe Java Object. Il existe une association entre les classes Java ArrayList et Object parce que, dune part, un objet de type ArrayList est compos dun tableau dlments de type Object et que, dautre part, toute classe Java hrite de la classe Object. La classe Personne hrite donc de la classe Object. Ces relations font quun rpertoire peut contenir un tableau de personnes. Cette relation nest pas rete par le modle UML, car il ne contient pas la classe Objet. Ajouter cette classe au modle UML ncessiterait dtablir les liens entre elle et toutes les autres classes, ce qui nest gure envisageable.
29. Comment modier les rgles du Reverse Engineering pour faire en sorte quune association soit tablie entre la classe Repertoire et la classe Personne ?
Dans notre cas, nous pouvons tablir cette association, puisque lattribut de type ArrayList de la classe Repertoire ne contient que des lments de type Personne. Cet attribut peut donc tre reprsent par une association entre les classes Repertoire et Personne. Cela nest cependant pas toujours possible, car un objet de type ArrayList contient des lments de type Object. Puisque toutes les classes hritent de la classe Object, un objet de type ArrayList peut thoriquement contenir des lments de nimporte quel type, et ils ne sont pas tous obligatoirement de mme type. Lassociation entre la classe ayant une proprit de type ArrayList et la classe reprsentant le type des objets contenus dans le tableau dynamique (ArrayList) nest donc pas toujours possible. Nous dirons donc que si, dans Java, un attribut dune classe A est de type ArrayList et que le code montre que tous les objets ajouts au tableau dynamique sont de mme type (reprsent par une classe B), nous pouvons mettre une association de la classe A vers la classe B. Attention : les associations peuvent se dduire des types des attributs, mais non des types des paramtres des oprations de la classe. Si une opration de la classe A a un paramtre de type B, rien ne dit que ce paramtre est une information accessible directement depuis la classe A. Il peut tre le rsultat dune opration appele par la classe A. Il ny a donc pas lieu dassocier les classes A et B.
139
30. Effectuez le Reverse Engineering de la classe UIPersonne.
Les informations se trouvent dans le code de la classe UIPersonne. Nous constatons tout dabord que la classe UIPersonne hrite de la classe JPanel, relation qui doit apparatre dans le modle UML. Nous ajoutons donc une classe JPanel dont hrite la classe UIPersonne. La classe UIPersonne contient onze attributs, un de type Personne et les dix autres de type JtextField. Lattribut de type Personne est reprsent par une association navigable entre la classe UIPersonne et la classe Personne. Le nom de rle associ la classe Personne est personne, et la multiplicit associe est 0..1. Pour les autres attributs, nous ajoutons au modle la classe JFextField, et nous crons une association navigable entre la classe UIPersonne et la classe JTextField pour chacun des attributs. Pour chacune de ces associations, le rle associ la classe JTextField correspond au nom de lattribut Java, et la multiplicit associe est 0..1. Nous ajoutons la classe UML les cinq oprations suivantes, auxquelles nous ajoutons en note le code Java associ :
+UIPersonne() +UIPersonne(in p:Personne) +getPersonne():Personne +setPersonne(in personne:Personne) +init()
Il est important de noter que les rgles de Reverse Engineering que nous avons dnies ne permettent pas de prendre en considration la classe anonyme cre par lopration init. La gure 15 reprsente les liens (hritage ou association) entre la classe UIPersonne et les classes JPanel, Personne et JTextField.
31. Comment introduire les classes Java dans le modle UML ? quoi cela sert-il ?
Il faut appliquer une opration de Reverse Engineering sur le code de lAPI Java qui se trouve dans le chier rt.jar. Il faut donc disposer des sources de lAPI et avoir des rgles de Reverse Engineering sappliquant ce type de source. Il nest pas forcment judicieux de traiter de la mme manire le Reverse Engineering dune application complte et celui dune archive (chier .jar en Java) regroupant un ensemble de classes et les ressources associes. En fait, il nest pas intressant dintroduire dans le modle UML toutes les informations quil est possible dobtenir sur lAPI Java (telles que les liens entre les classes de lAPI). Lobjectif est uniquement dintroduire les classes de lAPI apparaissant directement dans le code an de pouvoir les rfrencer et les lier aux classes de lapplication. Ces liens sont indispensables pour pouvoir raliser la gnration de code.
140
Personne
JPanel personne 0..1
UIPersonne
0..1
0..1 0..1 tel faxTF prenom telPort socTF mailTF addTF titreTF faxTX telBur nomTF Maison TF TF TF TF JTextField
0..1
0..1
0..1
0..1
0..1
0..1
0..1
0..1
Figure 15
Associations entre UIPersonne et JTextField
32. Est-il plus facile de comprendre une application aprs en avoir effectu le Reverse Engineering ?
Lopration de Reverse Engineering ne facilite pas la comprhension dune application. Il ne sagit que de reprsenter graphiquement le code. Les diagrammes obtenus ne sont que la vue structurelle au niveau dabstraction le plus bas de lapplication. Pour comprendre facilement lapplication, il faut produire les diagrammes associs chacune des vues pour chacun des niveaux dabstraction.
33. Les informations obtenues aprs Reverse Engineering sont-elles plus abstraites que le code Java ?
Non, les informations sont quivalentes. Le modle obtenu aprs Reverse Engineering ne reprsente que les informations contenues dans le code. La preuve en est que notre modle contient des classes Java.
141
34. Le modle obtenu par Reverse Engineering contient-il plus de diversit que le code ?
Si, comme nous le prconisons, le Reverse Engineering produit plusieurs diagrammes de classes, le modle obtenu offre un peu plus de diversit que le code. Cependant, il nous permet uniquement dobtenir la vue structurelle de lapplication. Une analyse plus pousse du code pourrait nous permettre dobtenir des informations sur le comportement et les fonctionnalits de lapplication. Mais la mise en place de cette analyse rendrait lopration de Reverse Engineering beaucoup plus dlicate, car lidentication des nouveaux diagrammes produire et des classes faire apparatre dans ces diagrammes nest pas vidente. Il est difcile dautomatiser ces oprations, dont le rsultat dpend beaucoup de lexprience de celui qui les ralise. Les rgles que nous donnons pour le Reverse Engineering sont facilement automatisables et doivent donc toujours produire le mme rsultat pour un code donn.
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 Reverse Engineering ?
Comme nous venons de le voir, lapplication de nos rgles de Reverse Engineering produit des rsultats dterministes. Pour un code donn, pour un ensemble de rgles donn, le rsultat du Reverse Engineering sera toujours le mme, alors quun tre humain ne ferait pas toujours les mmes choix et ajusterait ses dcisions en fonction de divers facteurs. Dans notre cas, nous pouvons dire que, si le modle contient, par exemple, des liens avec la classe ArrayList ou si toutes les associations sont navigables lune de leurs extrmits et que les multiplicits soient 0..1, alors le modle a t obtenu par Reverse Engineering. De faon gnrale, plus les mcanismes de Reverse Engineering sont simples mettre en uvre, plus ils sont identiables, puisquils nautorisent pas de varit dans les traitements raliss. Cependant, il est parfois possible de paramtrer lopration de Reverse Engineering et donc de diversier les traitements en fonction des particularits du code considr (application complte, API Java, etc.).
TD4. Rtroconception et patrons de conception

La gure 16 reprsente les relations entre les classes Synchronisateur et Calculateur. Un calculateur permet deffectuer des calculs. Etant donn que nimporte qui peut demander un calculateur deffectuer des calculs, la classe Synchronisateur a t construite pour rguler les calculs. Les personnes qui souhaitent demander la ralisation dun calcul doivent passer par le synchronisateur (via lopration calculer()). Celui-ci distribue les calculs aux diffrents calculateurs avec lesquels il est li (cest lui qui appelle lopration calculer() sur les calculateurs). Un calculateur connat le synchronisateur auquel il est reli grce la proprit sync de type Synchronisateur. Sa valeur doit tre dtermine lors de la cration des objets de type Calculateur.
Figure 16
Classes Synchronisateur et Calculateur
calculateur *
Calculateur -sync : Synchronisateur +calculer()
142
36. Exprimez en les justiant les dpendances entre les classes Synchronisateur et Calculateur.
Lassociation navigable de la classe Synchronisateur vers la classe Calculateur tablit une dpendance de la classe Synchronisateur vers la classe Calculateur. La proprit sync de type Synchronisateur de la classe Calculateur tablit une dpendance de la classe Calculateur vers la classe Synchronisateur.
37. Nous souhaitons que les classes Synchronisateur et Calculateur soient dans deux packages diffrents. Proposez une solution.
Comme nous venons de le voir la question prcdente, il y a un cycle de dpendances entre les classes Calculateur et Synchronisateur. Nous ne pouvons nous contenter de les mettre dans deux packages diffrents, car il faudrait alors tablir une dpendance mutuelle entre ces deux packages. Nous devons donc dporter une des causes du cycle de dpendances hors de sa classe dorigine. Nous ne considrons que la classe Calculateur et choisissons de dporter lopration calculer() de la classe Calculateur, qui est lorigine de la dpendance de la classe Synchronisateur vers la classe Calculateur. Lassociation est l pour permettre un synchronisateur didentier les calculateurs qui dpendent de lui et de pouvoir appeler leur opration calculer(). Nous crons donc une classe CalculateurSup, dont hrite la classe Calculateur et qui contient lopration calculer(). Lassociation est de la sorte elle aussi dporte de la classe Calculateur vers la classe CalculateurSup. Nous pouvons mettre dans un mme package les classes Synchronisateur et CalculateurSup et dans un autre la classe Calculateur. Les dpendances sont alors internes un package (association entre les classes Synchronisateur et CalculateurSup) ou du package contenant la classe Calculateur vers lautre package (dpendances dues la relation dhritage de la classe CalculateurSup par la classe Calculateur et la proprit de type Synchronisateur de la classe Calculateur).
calculateur * CalculateurSup +calculer ()
Calculateur -sync : Synchronisateur +calculer ()
Figure 17
Suppression du cycle de dpendances
La gure 17 reprsente lensemble des liens existant entre les classes Synchronisateur, CalculateurSup et Calculateur. Nous avons matrialis par un trait la sparation en deux packages. Il est noter que lopration calculer() est bien dclare dans la
143
classe CalculateurSup, alors quelle nest que rpte dans la classe Calculateur, ce qui nest pas obligatoire. Nous pourrions aussi envisager de rsoudre le problme en dportant la proprit sync de la classe Calculateur, mais cela ne ferait qu agrandir le cycle de dpendances. La dpendance de la classe Synchronisateur vers la classe Calculateur ne peut tre dporte, car elle est lie lopration calculateur(), qui reste dans la classe Calculateur. La classe Calculateur hrite de la classe CalculateurSup, qui, elle mme, dpend de la classe Synchronisateur en raison de sa proprit. La gure 18 reprsente cette mauvaise solution en mettant en vidence le cycle de dpendances.
Figure 18
chec de la suppression du cycle de dpendances
CalculateurSup -synch : Synchronisateur
calculateur
Calculateur +calculer()
38. Nous souhaitons ajouter la classe Synchronisateur une opration ajouterCalculateur() qui permette dassigner un calculateur un synchronisateur, lidentit du calculateur tant un paramtre dentre de lopration. Dnissez cette opration.
La seule difcult est de faire attention ne pas crer un cycle de dpendances en ajoutant cette opration. Les dpendances nouvelles cres lors de lajout dune opration proviennent des paramtres de lopration. Il ne faut absolument pas quune dpendance soit cre de la classe Synchronisateur vers la classe Calculateur. Le type du paramtre de lopration doit donc tre la classe CalculateurSup. Lopration ajouter dans la classe Synchronisateur est alors declarerCalculateur(in recepteur:CalculateurSup).
calculateur * CalculateurSup +calculer ()
Synchronisateur +calculer() +ajouterCalculateur()
Calculateur -sync : Synchronisateur +calculer ()
Figure 19
Ajout de lopration ajouterCalculateur()
144
La gure 19 reprsente les trois classes Synchronisateur, CalculateurSup et Calculateur, ainsi que les liens tablis entre ces classes.
39. Nous souhaitons maintenant dnir une classe reprsentant une barre de progression. Cette barre afche ltat davancement du calcul (en pourcentage). Une barre de progression reoit des messages dun calculateur qui linforme que ltat davancement du calcul a chang. Dnissez cette classe.
La gure 20 reprsente la classe BarreProgression, qui contient lopration avancement().

Figure 20
Classe BarreProgression
BarreProgression +avancement()
40. Tout comme le synchronisateur, une barre de progression doit se dclarer auprs dun calculateur. De plus, le calculateur doit offrir une opration permettant de connatre le pourcentage davancement du calcul. Dnissez les associations et oprations ncessaires.
Il faut modier la classe Calculateur. La barre de progression devant se dclarer auprs du calculateur, cest ce dernier qui contient lopration declarerBarre(). Pour que le calculateur puisse identier la barre qui se dclare, il faut que son identit soit passe en paramtre de lopration. Pour quune barre de progression puisse avoir accs ltat davancement du calcul, il faut crer une association allant de la classe BarreProgression vers la classe Calculateur et lopration getAvancement():integer dans la classe Calculateur. La multiplicit de lassociation est 0..1 lextrmit du calculateur et 0..* lextrmit de la barre de progression. Une barre de progression est associe au plus un calculateur, et nous faisons lhypothse quun calculateur est associ plusieurs barres de progression. La gure 21 reprsente les associations et oprations ajoutes aux classes BarreProgression et Calculateur.
Figure 21
Classes BarreProgression et Calculateur aprs modication
barre *
calculateur 0..1
Calculateur +declarerBarre() +getAvancement()
41. Appliquez le patron de conception Observer, et faites en sorte que ces deux classes soient dans deux packages diffrents.
Le diagramme donn en rponse la question prcdente montre quil y a un cycle de dpendances entre les classes BarreProgression et Calculateur. Il y a une association de la classe BarreProgession vers la classe Calculateur, et le paramtre de lopration declarerBarre() de la classe Calculateur est de type BarreProgression. Nous devons donc casser ce cycle an de pouvoir mettre les classes dans des packages diffrents.
145
Nous souhaitons le faire en appliquant le patron de conception Observer, ce qui est pertinent puisque le problme rsolu par ce patron de conception est : Crer un lien entre un objet source et plusieurs objets cibles permettant de notier les objets cibles lorsque ltat de lobjet source change. De plus, il faut pouvoir dynamiquement lier (ou dlier de) lobjet source autant dobjets cibles que nous le voulons. Dans notre cas, lobjet Observer est la barre de progression et lobjet Subject le calculateur, puisque notre problme est dinformer la barre de progression des avancements du calculateur. La classe Observer du patron de conception correspond une abstraction de la classe BarreProgression dont cette dernire hrite. Cest elle qui doit contenir la mthode par laquelle la barre de progression est informe des avancements du calculateur. La classe Subject du patron de conception correspond une abstraction de la classe Calculateur dont cette dernire hrite. Dans notre cas, cette classe contient lquivalent de lopration attach(in obs:Observer), qui, dans notre cas, est lopration declarerBarre(in barre:Progression) ainsi que lopration de notication tous les observateurs (notify()). laide de ce patron de conception, il est possible de faire une dcoupe en packages sparant les classes BarreProgression et Calculateur. La gure 22 reprsente lapplication du patron de conception Observer sur nos classes.
update() devient avancement()
attach() devient dclarerBarre()
Subject Observer +avancement() observer * +declarerBarre() +detach() +notify()
0..1 calculateur
Calculateur +declarerBarre() +getAvancement()
Figure 22
Application du patron Observer
146
TD5. Gnration de code

42. crivez le code gnr partir de la classe Document illustre la gure 5.5.
Figure 23
Classe Document
Daprs les rgles de correspondance UML vers Java que nous avons dnies, le code suivant est obtenu :
public class Document { public int id; public String titre; public int etat; public void dfinirEtat( int etat) { } }
Remarquons que les rgles suivantes ont t appliques : rgle n 1 pour la classe ; rgle n 3 pour toutes les proprits de la classe ; rgle n 4 pour lopration de la classe.
43. crivez le code gnr partir de la classe Bibliothque illustre la gure 24.
Figure 24
Classes Bibliothque et Document
Bibliothque ajouterDocument() listerDocument()
Document doc * id:integer titre:string etat:integer dfinirEtat()
Daprs les rgles de correspondance UML vers Java que nous avons dnies, le code suivant est obtenu :
public class Bibliothque { public java.util.ArrayList doc = new java.util.ArrayList(); public void ajouterDocument() { } public void listerDocument()
147
{ } }
Remarquons que les rgles suivantes ont t appliques : rgle n 1 pour la classe ; rgle n 4 pour les oprations de la classe ; rgle n 5 (deuxime version) pour lassociation vers la classe Document.
44. crivez le code gnr partir des classes Livre, CD et Revue reprsentes la gure 25.
Figure 25
Classes CD, Livre et Revue
CD CDDB:string
Livre ISBN:string
Revue ISSN:string
Daprs les rgles de correspondance UML vers Java que nous avons dnies, et plus particulirement grce la rgle n 6, le code suivant est obtenu :
public class CD extends Document { Public String CDDB; } public class Livre extends Document { Public String ISBN; } public class Revue extends Document { Public String ISSN; }
45. crivez le code gnr partir de lassociation CDdeLivre reprsente la gure 26 aprs avoir dni les rgles de gnration de code que vous comptez utiliser.
Figure 26
Association CDdeLivre
CD CDDB:string
cd *
CDdeLivre livre 0..1
Livre ISBN:string
148
Aucune des rgles de correspondance UML vers Java que nous avons rappeles au chapitre 5 ne permet de traiter les associations non navigables. Nous pouvons proposer la rgle suivante : Pour toute association non navigable, crer une classe Java. Le nom de la classe Java doit correspondre au nom de lassociation. Pour chacunr des deux extrmits de lassociation, crer un attribut dans la classe Java. Le nom de lattribut doit correspondre au nom du crochet. Le type de lattribut doit correspondre la correspondance Java de la classe UML attache lextrmit. Si lextrmit spcie que le nombre maximal dobjets pouvant tre relis est suprieur 1, lattribut Java est un tableau. En appliquant cette rgle lassociation CDdeLivre, nous obtenons le code suivant :
public class CDdeLivre { CD[] cd ; Livre livre ; }
Les objets Java instances de cette classe permettront ainsi de reprsenter des liens entre un livre et des CD.
46. crivez le code gnr partir des classes reprsentes la gure 27 aprs avoir dni les rgles de gnration de code que vous comptez utiliser.
Figure 27
Hritage multiple
Oeuvre
CD CDDB:string
Livre ISBN:string
Aucune des rgles de correspondance UML vers Java rappeles au chapitre 5 ne permet de traiter lhritage multiple. Soulignons que la transformation dun modle hritage multiple vers un modle hritage simple est un problme complexe trs connu, mais sans solution facile mettre en place. Nous pouvons cependant proposer la rgle suivante, qui ne sapplique qu certains modles, dont celui de notre question : Pour tout modle hritage multiple dont seule une classe hrite possde des proprits (les autres classes hrites nen possdent pas) et dont toutes les classes
149
hrites nhritent pas dautres classes, crer une classe Java pour la classe hrite qui possde des proprits, crer une interface Java pour les autres classes hrites, crer une classe Java pour la classe qui hrite et faire en sorte que celle-ci tende la classe Java cre et ralise les interfaces Java cres. En appliquant cette rgle notre cas, nous obtenons le code ci-dessous. Le code de la classe Document est le mme que celui de la question 42 :
public interface Oeuvre { }
Le code des classes CD et Livre change an de raliser linterface Oeuvre :

public CD extends Document realize uvre { } public Livre extends Document realize uvre { }
Un mcanisme dupdate permet de faire remonter les modications du code Java dans le modle UML avec lequel il est dj synchronis. Par exemple, si nous considrons que le modle UML et le code Java de la classe Bibliothque sont synchroniss depuis la question 43 et que nous ajoutions dans le code lattribut nom la classe Bibliothque, alors celui-ci apparatra dans le modle UML aprs excution de lupdate. Nous considrons pour linstant que le mcanisme dupdate correspond une opration de Reverse Engineering du code Java, si ce nest que les lments du code qui napparaissaient pas dans le modle y sont directement ajouts.
47. Construisez le modle UML de la classe Bibliothque (dont vous avez fourni le code la question 43) obtenu par update aprs avoir ajout dans le code Java les attributs nom, adresse et type, dont les types sont des string.
Ces trois attributs, qui napparaissaient pas dans le modle, y sont ajouts selon les rgles de correspondance du Reverse Engineering. Nous obtenons la classe reprsente la gure 28.
Figure 28
Classe Bibliothque
Bibliothque nom:string adresse:string type:string ajouterDocument() listerDocument()
48. Nous voulons maintenant, toujours dans le code Java, changer lattribut type en attribut domaine. Pensez-vous quil soit possible, aprs un update, que les deux attributs type et domaine puissent tre prsents dans le modle ? Si oui, quoi est d ce comportement bizarre ?
la question prcdente, nous avons dni lupdate comme une opration ne faisant quajouter de nouveaux lments au modle UML. De ce fait, les lments ne sont jamais supprims du modle UML. Lupdate ne sait donc pas faire la diff-
150
rence entre lajout dun nouvel attribut et la modication dun attribut existant. Ds lors, il est tout fait envisageable dobtenir le modle UML de la classe Bibliothque reprsent la gure 29 avec les deux attributs type et domaine.
Figure 29
Classe Bibliothque aprs modication de la proprit type en domaine
Bibliothque nom:string adresse:string type:string domaine:string ajouterDocument() listerDocument()
La synchronisation entre le modle et le code nest plus faite.

49. Proposez un nouveau mcanisme dupdate ne souffrant pas des dfauts prsents la question prcdente.
Ce nouveau mcanisme dupdate doit tre capable de faire la diffrence entre lajout dun nouvel attribut et la modication dun attribut existant. Pour ce faire, lupdate doit tre capable de reconnatre chaque attribut Java et de vrier quil nexiste pas une proprit correspondante dans le modle UML. Si une proprit existe dj, il faut la modier. Lupdate doit donc lier les attributs Java aux proprits UML pour chaque classe. Ce lien ne peut se faire sur le nom des attributs et des proprits. En effet, la modication du nom de lattribut Java rendrait impossible la recherche de la proprit UML correspondante et entranerait les mmes problmes de perte de synchronisation. La solution classique ce problme consiste, dune part, introduire dans le code Java des commentaires permettant didentier chaque attribut et, dautre part, lier ces identiants aux identiants des proprits UML. Le code suivant de la classe Bibliothque illustre cette utilisation des commentaires :
public class Bibliothque { //attribut id1 public String nom; //attribut id2 public String adresse; //attribut id3 public String type; public java.util.ArrayList doc = new java.util.ArrayList(); public void ajouterDocument() { } public void listerDocument()
151
{ } }
En liant ces identiants aux identiants des proprits UML, il est possible de raliser une correspondance entre chaque attribut Java et chaque proprit UML et ainsi deffectuer les modications des proprits UML lorsque les attributs Java sont modis.
50. Proposez le mcanisme inverse de lupdate permettant de modier un modle UML dj synchronis avec du code et de mettre jour automatiquement le code Java.
Ce mcanisme ressemble fortement lupdate, si ce nest quil sappuie sur lopration de gnration de code. Les identiants des attributs Java doivent tout autant tre utiliss an de permettre la modication des proprits UML et la modication des attributs Java correspondants.
51. Dans quelle approche de programmation par modlisation (Model Driven, Code Driven et Round Trip) ces mcanismes dupdate sont-ils fondamentaux ?
Ce mcanisme est rellement ncessaire pour lapproche Round Trip, qui permet la modication du modle et du code nimporte quel moment et doit donc assurer nement la synchronisation. Ce mcanisme nest pas intressant pour les approches Model Driven ou Code Driven, car ces deux approches nutilisent lopration de gnration de code ou de Reverse Engineering quune fois.
TD6. Diagrammes de squence

Lapplication ChampionnatEchecs, qui doit permettre de grer le droulement dun championnat dchecs, est actuellement en cours de dveloppement. Lquipe de dveloppement na pour linstant ralis quun diagramme de classes de cette application (voir gure 30).
Figure 30
Classes de lapplication ChampionnatEchecs
ChampionnatDEchecs -MAX:integer -fermer:boolean +inscriptionJoueur() +gnrerParties() +obtenirPartiesDUnJoueur() +calculerClassementDUnJoueur() Joueur joueur * -numro:integer -nom:string -prnom:string
noir
blanc
partie
Partie -numro:integer -fini:boolean +jouerCoup() -verifierMat() -finirPartie()
152
La classe ChampionnatDEchecs reprsente un championnat dchecs. Un championnat se droule entre plusieurs joueurs (voir classe Joueur) et se joue en plusieurs parties (voir classe Partie). La proprit MAX de la classe ChampionnatDEchecs correspond au nombre maximal de joueurs que le championnat peut comporter. La proprit fermer permet de savoir si le championnat est ferm ou si de nouveaux joueurs peuvent sinscrire.
ChampionnatDEchecs possde les oprations suivantes : inscriptionJoueur(in nom:string, in prnom:string) : integer permettant dinscrire un nouveau joueur dans le championnat si le nombre de joueurs inscrits nest pas dj gal MAX et si le championnat nest pas dj ferm. Si linscription est autorise, cette opration cre le joueur et retourne son numro dans le championnat. gnrerPartie() : permet de fermer le championnat et de gnrer toutes les parties ncessaires. obtenirPartieDUnJoueur(in numro:integer):Partie[*] : permet dobtenir la liste de toutes les parties dun joueur (dont le numro est pass en paramtre). calculerClassementDUnJoueur(in numro:interger) : integer permettant de calculer le classement dun joueur (dont le numro est pass en paramtre) pendant le championnat.
La classe Partie reprsente une des parties du championnat. La classe Partie est dailleurs associe avec la classe ChampionnatDEchecs, et lassociation prcise quun championnat peut contenir plusieurs parties. Une partie se joue entre deux joueurs. Un joueur possde les pices blanches et commence la partie alors que lautre joueur possde les pices noires. Les associations entre les classes Partie et Joueurs prcisent cela. La proprit numro correspond au numro de la partie (celui-ci doit tre unique). La proprit fini permet de savoir si la partie a dj t joue ou non. La classe Partie possde les oprations suivantes : jouerCoup(in coup:string) : permet de jouer un coup tant que la partie nest pas nie. Le traitement associ cette opration fait appel lopration vrifierMat an de savoir si le coup jou ne met pas n la partie. Si tel est le cas, lopration finirPartie est appele. vrifierMat() : boolean permettant de vrier si la position nest pas mat. finirPartie : permet de prciser que la partie est nie. Il nest donc plus possible de jouer de nouveaux coups. La classe Joueur reprsente les joueurs du championnat. La classe Joueur est dailleurs associe avec la classe ChampionnatDEchecs, et lassociation prcise quun championnat peut contenir plusieurs joueurs. La proprit numro correspond au numro du joueur (celui-ci doit tre unique). Les proprits nom et prnom permettent de prciser le nom et le prnom du joueur. Un championnat dchecs se droule comme suit : Un administrateur de lapplication cre un championnat avec une valeur MAX. Les participants peuvent sinscrire comme joueurs dans le championnat. Ladministrateur cre lensemble des parties. Les participants, une fois inscrits, peuvent consulter leur liste de parties. Les participants, une fois inscrits, peuvent jouer leurs parties. Nous ne nous intressons qu'aux coups jous par chacun des deux joueurs. Nous ignorons l'initialisation de la partie (identication du joueur qui a les pions blancs et donc qui commence la partie). Les participants peuvent consulter leur classement.
153
Dans les questions suivantes, nous allons spcier des exemples dexcution de ChampionnatDEchecs avec des diagrammes de squence. 52. Comment modliser les administrateurs et les participants ?
Les administrateurs et les participants ne font pas partie de lapplication, mais ils lutilisent. Voil pourquoi, il nexiste pas de classe Administrateur ni Participant. Il est trs important de distinguer le participant de linstance de la classe Joueur. Linstance de la classe Joueur est un objet qui fait partie de lapplication et qui contient diffrentes informations sur un participant. Pour faire apparatre les participants et les administrateurs dans les diagrammes de squence, il faut utiliser des objets non typs.
53. Reprsentez par un diagramme de squence le scnario dexcution correspondant la cration dun championnat et linscription de deux joueurs. Vous assurerez la cohrence de votre diagramme avec le diagramme de classes fourni la gure 30.
Le diagramme de squence solution reprsent la gure 31 contient six objets. Lobjet ladministrateur nest pas typ et reprsente ladministrateur. Les objets MrBF et MrBS ne sont pas typs non plus et reprsentent respectivement les deux participants au championnat. Lobjet umlOne est instance de la classe ChampionnatDEchecs et reprsente le championnat. Les objets bf et bs sont instances de la classe Joueur et reprsentent les deux joueurs du championnat. Le diagramme de squence spcie que ladministrateur commence par crer lobjet umlOne puis que MrBF et MrBS demandent sinscrire au championnat en donnant leur nom et leur prnom. En rponse aux deux demandes dinscription, umlOne cr les deux objets bf et bs instances de la classe Joueur et retourne les numros didentication des joueurs.
bossAdministrateur MrBF MrBS cration umlOne:ChampionnatDEchecs inscriptionJoueur ("bobby","fisher") cration 1 bf:Joueur
inscriptionJoueur("Boris","Spassky") cration 2 bs:Joueur
Figure 31
Diagramme de squence reprsentant des inscriptions
54. Reprsentez par un diagramme de squence le scnario dexcution correspondant la cration de lensemble des parties pour le championnat cr la question 53. Vous assurerez la cohrence de votre diagramme avec le diagramme de classes fourni la gure 30.
154
Le diagramme de squence solution reprsent la gure 32 contient trois objets. Lobjet ladministrateur est le mme qu la question 53. Il demande lobjet umlOne de raliser lopration gnrerPartie(). Celui-ci, qui est aussi le mme objet qu la question prcdente, cre une seule partie, reprsente par lobjet p1 instance de la classe Partie, car le championnat ne contient que deux joueurs.
Figure 32
Diagramme de squence reprsentant la gnration des parties
l'administrateur
umlOne:ChampionnatDEchecs
gnrerParties() cration p1:Partie
55. Reprsentez par un diagramme de squence le scnario dexcution correspondant au droulement de la partie dchecs entre deux joueurs. Vous pouvez considrer une partie qui se termine en quatre coups. Vous assurerez la cohrence de votre diagramme avec le diagramme de classes fourni la gure 30.
Le diagramme de squence solution reprsent la gure 33 contient trois objets. Les objets MrBF et MrBS sont les mmes qu la question 53. Lobjet p1 est le mme qu la question 54. Ce diagramme spcie les diffrents coups jous par les deux participants et le fait que nous vrions chaque coup que la position nest pas mat. Au dernier coup, la position est mat. La partie est donc termine.
56. Est-il possible de gnrer automatiquement le code dune opration de cette application partir de plusieurs diagrammes de squence ?
Comme nous lavons vu en cours, il nest pas rellement possible de gnrer le code dune opration. Cela est particulirement agrant avec lopration jouerCoup. Nous voyons bien quil nest pas possible de raliser tous les diagrammes de squence correspondant toutes les excutions possibles de cette opration.
57. Est-il possible de construire des diagrammes de squence partir du code dune application ?
Lorsque nous disposons du code dune application, il est possible de lexcuter. De ce fait, il est possible de construire un diagramme de squence reprsentant scrupuleusement cette excution. Par exemple, nous pourrions excuter lapplication de gestion de championnat dchecs pour un championnat particulier et modliser cette excution dans un diagramme de squence. Notons que cette fonctionnalit est par ailleurs souvent propose par les outils du march.

Figure 33
155
Diagramme de squence reprsentant une partie
MrBF
MrBS jouerCoup("f4")
p1:Partie
vrifierMat() faux jouerCoup("e6")
vrifierMat() faux jouerCoup("g4") vrifierMat() faux
jouerCoup("Dh4") vrifierMat() vrai
finirPartie() ok
Il est important de noter que les diagrammes obtenus ne reprsentent quune excution de lapplication. Lensemble des diagrammes de squence obtenus partir du code de lopration ne peuvent donc tre utiliss ultrieurement des ns de gnration automatique de code.
Une quipe de dveloppement souhaite raliser une application Calculus permettant des utilisateurs deffectuer des oprations arithmtiques simples sur des entiers : addition, soustraction, produit, division. Cette application a aussi une fonction mmoire, qui permet lutilisateur de stocker un nombre entier quil pourra ensuite utiliser pour n'importe quelle opration. Les oprations peuvent seffectuer directement sur la mmoire. Lutilisateur se connecte et ouvre ainsi une nouvelle session. Puis, dans le cadre dune session, il peut demander au systme deffectuer une suite doprations.
156
58. Utilisez des diagrammes de squence pour reprsenter les diffrents scnarios dexcution du service Calculus.
Lobjectif de cette question est dillustrer le fait quil est possible de commencer modliser une application par llaboration de squences plutt que par llaboration de classes. Le diagramme reprsent la gure 34 spcie une demande de cration de session puis la ralisation dune addition et dune multiplication.
Figure 34
Diagramme de squence reprsentant une addition et une multiplication
l'utilisateur
applicationPrincipale
crerSession cration nouvelleSession
addition(1,2)
multiplication(2,1) 2
Le diagramme reprsent la gure 35 spcie une demande de cration de session puis laffectation de la mmoire 2, puis lajout de 2 la mmoire (la mmoire contient donc 4).
59. Pour chacune des instances apparaissant dans votre diagramme de classes, crez la classe correspondante.
Les diagrammes de squence que nous avons proposs la question 58 nous permettent de proposer le diagramme de classes reprsent la gure 36. Ainsi, lobjet applicationPrincipale est-il instance de la classe ApplicationArtihmtique et lobjet nouvelleSession est-il instance de la classe Session. En multipliant ainsi les diagrammes de squence, nous pouvons obtenir un diagramme de classes beaucoup plus complet.

Figure 35
157
Diagramme de squence reprsentant un ajout dans la mmoire
l'utilisateur
applicationPrincipale
crerSession cration nouvelleSession
stockerMmoire(2)
ajouterMmoire(2) 4
Figure 36
Classe ApplicationArithmtique
ApplicationArithmtique +crerSession() : Session
session
Session +stockerMmoire() +ajouterMmoire() +addition() +multiplication ()
Nos diagrammes de squence ne font pas apparatre les oprations soustraction(), division(), soustraireMmoire(), diviserMmoire(), multiplierMmoire(), etc., que lapplication devrait logiquement offrir. Comme nous dduisons notre diagramme de classes des diagrammes de squence, il est logique que ces oprations napparaissent pas non plus dans la classe Session.
158
TD7. Diagrammes de squence de test

La classe Partie de lapplication de gestion de championnat dchecs prsente au TD6 reprsente une partie dchecs. Elle permet aux joueurs de jouer leur partie en appelant lopration jouerCoup(). Chaque fois quun coup est jou, lopration vrifierMat() est appele an de vrier que la position nest pas mat. Si tel est le cas, la partie est nie. Aucun coup ne peut alors tre jou (voir TD6 pour la modlisation de classe Partie ainsi quun diagramme de squence spciant un cas nominal de droulement dune partie entre deux joueurs). 60. Identiez une faute qui pourrait intervenir lors du droulement dune partie.
Une faute potentielle serait que lopration vrifierMat() ne retourne pas vrai alors que la partie est rellement mat. Si tel tait le cas, la partie ne serait pas nie, et les joueurs pourraient continuer jouer leurs coups. linverse, une autre faute serait que lopration vrifierMat() retourne vrai alors que la partie nest pas mat. Si tel tait le cas, la partie serait nie, et les joueurs ne pourraient plus continuer jouer leurs coups.
61. Dnissez un cas de test abstrait visant rvler cette faute.
Si nous nous concentrons sur la premire faute que nous avons identie la question 60, un cas de test abstrait visant rvler cette faute serait de simuler le jeu dune partie jusqu un mat. Le rsultat attendu serait que la partie soit ferme lissue de la simulation.
62. Construisez un diagramme de squence de test modlisant le cas de test abstrait de la question prcdente.
Comme illustr la gure 37, le diagramme de cas de test doit contenir le testeur (objet gauche du diagramme). Celui-ci doit crer lobjet tester (lobjet instance de la classe Patie), puis le testeur doit stimuler lobjet tester. Dans notre cas, le testeur fait semblant de jouer une partie jusquau mat. Enn, le diagramme de cas de test doit spcier le rsultat attendu. Dans notre cas, la partie doit tre nie. La suite de coups reprsente dans le diagramme suivant correspond une partie relle amenant au mat du roi blanc en quatre coups.
63. crivez le pseudo-code Java du cas de test excutable correspondant au cas de test abstrait de la question prcdente.
En suivant les rgles de correspondance dcrites dans le cours, nous obtenons le code suivant :
public class Test extends TestCase{ public void testExecutable() { p1 = new Partie(); p1.jouerCoup("f4") ; p1.jouerCoup("e6") ; p1.jouerCoup("g4") ; p1.jouerCoup("Dh4") ; assertTrue(p1.fini) ; } }.

Figure 37
159
Diagramme de squence de test de la classe Partie
testeur: cration p1:Partie jouerCoup("f4")
jouerCoup("e6")
jouerCoup("g4")
jouerCoup("Dh4")
rsultat attendu: p1.fini = true
La dernire ligne de ce code permet de vrier que la partie est bien termine.
64. Si ce cas de test ne rvle pas de faute, est-ce que cela signie que lapplication ne contient pas de dfaillance ?
Absolument pas. Cela signie simplement que, pour cette suite de coups (f4, e6, g4, Dh4), lapplication ne rvle pas de faute. Une autre suite de coups pourrait rvler une faute qui indiquerait que lapplication contient une dfaillance.
65. Combien de cas de test faudrait-il laborer pour amliorer la qualit de lapplication ?
Malheureusement, raliser un grand nombre de cas de test noffre pas plus de garantie sur la non-existence de dfaillance dans une application. Cela se voit bien dans ce cas, puisquil faudrait raliser un cas de test abstrait pour chaque partie dchecs imaginable. Lapplication permettant la gestion de championnat dchecs contient aussi la classe ChampionnatDEchecs, qui est associe la classe Partie et qui permet de grer linscription des joueurs et la cration des parties (voir TD6).
160
66. Identiez une faute qui pourrait intervenir lors de la cration des parties dun championnat. Dnissez un cas de test abstrait visant rvler cette faute, et construisez un diagramme de squence de test modlisant ce cas de test abstrait.
Une faute potentielle serait que toutes les parties du championnat ne soient pas cres ou quil y en ait plus que ncessaire. Il serait alors impossible tous les joueurs de jouer leurs parties ou la n du championnat ne serait jamais atteinte. Un cas de test abstrait permettant de rvler cette faute serait de construire un championnat avec deux joueurs et de vrier quaprs construction des parties, il existe bien exactement une seule partie. Le diagramme reprsent la gure 38 spcie ce cas de test abstrait. Le testeur cre linstance de la classe ChampionnatDEchecs. Il simule ensuite linscription de deux joueurs puis demande la gnration des parties. Le rsultat attendu est que le championnat ne contienne quune seule partie.
Figure 38
Diagramme de squence de test de la classe ChampionnatDEchecs
Testeur cration umlOne:ChampionnatDEchecs inscriptionJoueur("bobby","fisher")
inscriptionJoueur("Boris","Spassky")
2 gnrerParties()
rsultat attendu umlOne rfrence 1 seule partie
67. Est-il possible de lier les deux cas de test abstrait que vous avez dnis (un la question 61, lautre la question 66) ?
Il est en effet possible de dmarrer le cas de test abstrait de la question 61 aprs le cas de test abstrait de la question 66. Pour ce faire, il faudrait modier un peu le cas de test de la question 61 an de prciser que le testeur na pas crer la partie tester mais peut lobtenir puisquelle est lie au championnat dj cr.
161
TD8. Plates-formes dexcution

68. Le diagramme de classes de lagence de voyage reprsent la gure 39 correspond-til un modle conceptuel ou un modle physique ?
Hotel -name:string
hotel 0..1
Reservation -dateArrivee:string -dateDepart:string +setHotel()
* reservationEffectuee
hotelPropose
AgenceDeVoyage +obtenirReservation() +demanderTarifs()

Figure 39
Classes de lagence de voyage
Lapplication agence de voyage doit grer les rservations dhtels effectues par des clients. Les trois classes qui apparaissent dans le diagramme sont les objets mtier de lapplication. Les oprations offertes par ces classes sont les fonctions que nous souhaitons pouvoir raliser lors de la rservation dun htel : obtenir les tarifs dun htel et effectuer la rservation. Le diagramme reprsente donc les objets et fonctions mtier. Aucune information ne nous permet de lassimiler un modle physique : il ny a pas de classe Java et il ny a pas de classe ne reprsentant pas un objet mtier. Nous pouvons donc dire quil sagit dun modle conceptuel.
69. Pensez-vous quil soit intressant dappliquer des patrons de conception sur les modles conceptuels ?
Tout dpend du but dans lequel le patron de conception est utilis. Si lobjectif est de casser les dpendances et/ou de proposer une dcoupe du modle en packages, cela peut tre intressant. Nous obtenons des classes abstraites, des interfaces, des associations, des packages, etc., et ces objets ont tout fait leur place dans un modle 100 % UML sans quil soit ncessaire de le lier Java. Ils sont donc pertinents dans un modle conceptuel.
162
Si lobjectif est dappliquer les patrons en vue de bncier du code quils proposent, cela nest pas intressant, car nous intgrons un modle conceptuel des contraintes spciques une plate-forme dexcution. Prenons lexemple du patron de conception Singleton. Ce patron fait en sorte quil ny ait quune seule et unique instance dune classe dans une application. La mise en place de ce patron ne se fait que par du code (Java par exemple) :
public class A { static singleton = new A(); public A () { return singleton ; }
Ce patron de conception nest donc pas applicable en 100 % UML (modle conceptuel), car sa mise en place ncessite lintgration de code dans le modle. Le patron de conception Observer, que nous avons dj vu, est en partie applicable, car une partie de son utilisation consiste en la cration de classes et dassociations entre elles (dcoupe en classe abstraite, hritage, etc.). Par contre, le code des oprations du patron de conception nest pas utilisable (mthodes attach(), notifyAll(), etc.) puisquil ne sagit pas dinformations 100 % UML. Nous venons de voir que lapplication de patrons de conception au niveau conceptuel tait possible et utile mais quelle devait tre effectue avec prcaution pour ne pas introduire des considrations physiques l o elles ne doivent pas se trouver.
70. Le diagramme de squence reprsent la gure 40 est-il conceptuel ou physique ? Notez quil fait intervenir une opration qui napparat pas dans le diagramme de classes initial. Quelle classe doit possder cette opration ?
client: ag:AgenceDeVoyage
obtenirReservation("Ritz","15juin","16juin") cration resa:Reservation addReservationEffectuee(resa)
ok
Figure 40
Interaction reprsentant une rservation
163
Les classes nommes qui apparaissent dans ce diagramme de squence sont les classes du modle conceptuel. Il sagit donc dun diagramme de squence conceptuel. Un diagramme de squence dun certain niveau dabstraction ne peut faire intervenir que des classes du mme niveau dabstraction. Lopration qui a t ajoute est addReservationEffectuee(). Le diagramme de squence montre quelle doit tre mise dans la classe AgenceDeVoyage et quil sagit dune opration interne cette classe.
71. Serait-il possible de spcier en 100 % UML le comportement de lagence de voyage ?
Les modles UML que nous considrons utilisent les diagrammes de squence pour reprsenter la partie comportementale dune application. Pour pouvoir spcier en 100 % UML le comportement de lagence de voyage, il faudrait donc produire un ensemble de diagrammes de squence reprsentant de manire exhaustive lensemble des comportements possibles de lapplication. En rgle gnrale, cest impossible puisque le nombre de diagrammes produire est trop important. Dans notre cas, cest totalement impossible, parce quun certain nombre de donnes peuvent prendre un nombre inni de valeurs (attributs de type string) et que les diagrammes de squence doivent prendre en compte toutes les valeurs possibles. Nous ne pouvons donc pas spcier en 100 % UML le comportement de lagence de voyage laide de diagrammes de squence. Il est important de noter que si dautres diagrammes UML sont pris en considration, le problme peut trouver une solution en 100 % UML. Nous avons pris le parti dans ce cours de ne prsenter que les trois plus importants des diagrammes UML, car ils sont sufsants pour lapproche que nous utilisons.
72. Serait-il possible de spcier en 100 % UML des tests pour lagence de voyage ? Justiez lintrt de ces tests.
Oui, rien ne lempche. Il faut toutefois avoir conscience que ces tests seraient des tests abstraits, donc non excutables. Il faudrait ds lors faire les tests physiques correspondants pour quils soient excutables aprs gnration du code.
73. Le diagramme reprsent la gure 41 est une concrtisation du diagramme conceptuel de lagence de voyage. Exprimez les relations dabstraction entre les lments des deux diagrammes.
Il sagit didentier les relations dabstraction entre les lments du diagramme physique et ceux du diagramme conceptuel. Les lments considrer sont les classes et les associations. Il faut garder en mmoire que tout lment du niveau conceptuel doit tre associ au moins un lment du niveau physique. Linverse nest pas vrai. Nous devons donc trouver les lments reprsentant la concrtisation de : la classe Hotel ; la classe Reservation ; la classe AgenceDeVoyage ; lassociation hotelPropose ;
164
Hotel -name:string
hotel 0..1
Reservation -dateArrivee:string -dateDepart:string
reservationEffectuee
0..1
ArrayList
AgenceDeVoyage +obtenirReservation() +demanderTarifs ()
0..1
hotelPropose
Iterator +next() +hasNext() Reservation res=null; for (Iterator it = reservationEffectuee.iterator() ; it.hasNext() ; ) { Reservation current = (Reservation) it.next(); if (current.dateArrivee == dateArrivee && current.dateDepart == dateDepart && current.hotel.name == hotelName) return current; } res = new Reservation(dateArrivee , dateDepart); res.setHotel(new Hotel( )); return res ; }
Figure 41
Classes du niveau physique de lagence de voyage
lassociation hotel ; lassociation reservationEffectuee. Pour les classes, cest assez facile et naturel. Chaque classe du modle conceptuel est labstraction de la classe de mme nom du modle physique. Lassociation hotel de multiplicit 0..1 est concrtise par lassociation de mme nom avec la mme multiplicit. Les associations hotelPropose et reservationEffectuee sont un peu plus dlicates grer car elles ont une multiplicit *. Elles sont concrtises par lassociation de mme nom, et la classe ArrayList est utilise pour reprsenter la multiplicit *. La classe ArrayList participe donc la concrtisation de deux relations. Il faut noter que la classe Iterator nest la concrtisation daucune classe du niveau conceptuel. Les relations dabstraction entre diagrammes de classes peuvent tre ajoutes aux diagrammes UML.
74. Quel est lintrt davoir fait apparatre les classes ArrayList et Iterator dans le modle concret (considrez en particulier la gnration de code et le Reverse Engineering) ?
Lintrt est davoir un modle physique trs proche du code Java. Ainsi, lopration de gnration de code (et de Reverse Engineering) est-elle beaucoup moins complexe et donc beaucoup plus sre. Mais, comme nous lavons vu avec la classe ArrayList et les
165
deux associations du niveau conceptuel la concrtisation desquelles elle participe, tablir les relations dabstraction entre le modle conceptuel et les lments physiques trs prs du code nest pas simple. La classe Iterator nous montre en outre que certains lments du modle physique ne sont relis avec aucun lment du modle conceptuel. Elle est juste prsente pour la gnration de code Java. En fait, plus le modle physique est proche de Java, moins la gnration de code est complexe, mais plus les relations dabstraction sont importantes et complexes. linverse, moins le modle physique est proche de Java, plus la gnration de code est complexe, mais ltablissement des relations dabstraction en est normalement facilit.
75. Construisez le diagramme de squence concrtisant le diagramme de squence prsent la question 70.
Il sagit quasiment du mme diagramme, si ce nest que le addReservationEffectue devient add et se fait directement sur linstance de ArrayList lie lobjet ag. Cette instance de ArrayList est identie par reservationEffectuee dans le diagramme reprsent la gure 42.
reservationEffectuee: ArrayList
client:
ag:AgenceDeVoyage
obtenirReservation("Ritz","15juin","16juin")
cration resa:Reservation
add(resa)
ok
Figure 42
Interaction du niveau physique reprsentant une rservation
76. Exprimez les relations dabstraction entre les diagrammes de squence.
Les relations dabstraction ne peuvent apparatre entre diagrammes de squence. Notre modle ne nous permet donc pas de les exprimer.
166
TD9. Diagrammes de cas dutilisation

Le diagramme de cas dutilisation de la gure 43 reprsente les fonctionnalits dune agence de voyage classique.
Agence De Voyage
Raliser Devis
include
Annuler Reservation
Client
Rserver Voyage
include include
Donner Cheque
Payer Voyage
extend
Faire un voyage
extend
Donner CD Payer sur le web Voyageur
Figure 43
Diagramme de cas dutilisation de lagence de voyage
77. Commentez les acteurs du diagramme de cas dutilisation.
Lacteur Client reprsente les clients de lagence et lacteur Voyageur reprsente les voyageurs. Comme il sagit dentits externes lapplication, rien ne garantit quun voyageur soit obligatoirement client de lagence. Donc, mme si certains voyageurs peuvent tre clients de lagence, il ne faut pas mettre de relation dhritage entre ces deux classes.
78. Commentez les cas dutilisation du diagramme de cas dutilisation.
Ce diagramme laisse croire que cest lagence de voyage qui soccupe de la ralisation du voyage, ce qui nest gnralement pas le cas. Lagence se charge normalement de vendre des voyages raliss par dautres. Il nest ds lors pas souhaitable dassocier ce cas dutilisation lapplication agence de voyage . Nous supprimons donc ce cas, et, en consquence, nous supprimons lacteur Voyageur, qui nest plus reli aucun cas dutilisation du diagramme. Le diagramme dutilisation de cette question reprsente les fonctionnalits du systme vis--vis des entits externes qui interagissent avec lui. Il sagit du diagramme de cas dutilisation dcrivant les fonctionnalits de lapplication au niveau besoin. Il ne faut donc faire apparatre que les fonctionnalits du systme (quels services rend le systme ?) et ne donner aucune information sur la faon dont ces fonctionnalits sont ralises (comment les services sont rendus ?).
167
Les relations dinclusion (include) reprsentent une dcoupe fonctionnelle. Elles nous informent que, pour raliser le cas dutilisation Reserver Voyage, il peut tre ncessaire de raliser les cas dutilisation Annuler Reservation et Payer Voyage. Ces informations nont rien faire au niveau besoin ; il sagit dinformations qui ont leur place au niveau conceptuel. Il en va de mme des relations dinclusion entre le cas dutilisation Payer Voyage et les cas dutilisation Donner Cheque et Donner CB. La relation dextension (extend) reprsente lajout dune fonctionnalit non prvue initialement dans le cas dutilisation Payer Voyage. Ici, il a t ajout la possibilit de payer la rservation par le Web. Dans ce cas prcis, cette extension nest pas justie, car ce cas dutilisation ne prsente pas une extension de comportement mais un troisime moyen de paiement, lequel na pas davantage sa place dans ce diagramme que les deux prcdents. Il est important de retenir que lapplication doit offrir au client la possibilit de faire une rservation, de payer une rservation, dannuler une rservation et dobtenir un devis. La gure 44 reprsente le diagramme de cas dutilisation que nous obtenons.
Figure 44
Diagramme de cas dutilisation de lagence de voyage aprs correction
Agence De Voyage
Raliser Devis
Crer Reservation
Client
Payer Complment Rservation
Annuler Reservation
79. Donnez la liste des acteurs du systme.
Nous souhaitons raliser le diagramme de cas dutilisation du championnat dchecs prsent au TD6. La description de lapplication donne au TD6 nous permet den identier trois : ladministrateur, le participant, qui reprsente un individu qui va sinscrire un championnat, et le joueur, qui reprsente un individu inscrit un championnat et qui peut donc participer aux parties auxquelles il est inscrit. Il ne faut pas tablir de lien dhritage entre les acteurs Participant et Joueur, car tous les participants ne sont pas des joueurs. Ils ne le deviendront quaprs stre
168
inscrits. Or tous les joueurs ne sont pas obligatoirement des participants puisque rien noblige un joueur sinscrire un nouveau championnat.
80. Donnez la liste des cas dutilisation du systme en les liant aux acteurs.
Les cas dutilisation associs ladministrateur sont : crer un championnat ; crer lensemble des parties associes un championnat. Les cas dutilisation associs au participant sont : sinscrire un championnat. Les cas dutilisation associs au joueur sont : consulter le calendrier lui donnant les informations sur sa liste de parties ; jouer les parties dun championnat ; consulter son classement.
81. Donnez le diagramme de cas dutilisation du systme.
Le diagramme de la gure 45 reprsente les cas dutilisation de lapplication du championnat dchecs.

Championnat dEchecs
S'inscrire un championnat en tant que joueur Participant
Ouvrir un championnat
Construire les parties d'un championnat Consulter calendrier des parties
Administrateur
Joueur
Consulter son classement
Jouer les parties d'un championnat
Figure 45
Diagramme de cas dutilisation du composant Championnat dEchecs
82. Reprenez les diagrammes de squence raliss au TD6 pour lapplication de championnat dchecs, et expliquez comment les relier au diagramme de cas dutilisation obtenu la question prcdente.
Il faut juste faire le lien entre les objets non typs des diagrammes de squence et les acteurs du diagramme de cas dutilisation. Ainsi, lobjet Ladministrateur devient-il
169
une instance de lacteur Administrateur. Dans le diagramme de squence reprsentant linscription un championnat, les objets MrBF et MrBS deviennent des instances de lacteur Participant. Dans le diagramme de squence reprsentant le droulement dune partie, les objets MrBF et MrBS deviennent des instances de lacteur Joueur.
TD10. Dveloppement avec UML

Une association dornithologie vous cone la ralisation du systme logiciel de recueil et de gestion des observations ralises par ses adhrents (le logiciel DataBirds). Lobjectif est de centraliser toutes les donnes dobservation arrivant par diffrents canaux au sein dune mme base de donnes, qui permettra ensuite dtablir des cartes de prsence des diffrentes espces sur le territoire gr par lassociation. Les donnes renseigner pour chaque observation sont les suivantes : Nom de lespce concerne. Il y a environ trois cents espces possibles sur le territoire en question. Si lobservation concerne plusieurs espces, renseigner plusieurs observations. Nombre dindividus. Lieu de lobservation. Date de lobservation. Heure de lobservation. Conditions mto lors de lobservation. Nom de chaque observateur. Quelle que soit la faon dont sont collectes les donnes, celles-ci sont saisies dans la base dans un tat dit valider . Tant que les donnes ne sont pas valides par les salaris de lassociation, des modications peuvent tre apportes aux donnes. La validation des donnes se fait uniquement par les salaris de lassociation qui ont le droit de modier la base de DataBirds. Ils doivent vrier que les donnes saisies sont cohrentes. Plus prcisment, ils doivent valider les noms des observateurs (les noms doivent correspondre des noms dadhrents) et lespce (celle-ci doit correspondre une espce connue sur le territoire). Aprs validation, une saisie se trouve soit dans ltat dit valid , soit dans ltat dit non valid . Les saisies dans ltat non valid sont automatiquement purges de la base une fois par semaine. Grce aux donnes saisies et valides, lassociation souhaite pouvoir tablir diffrents types de cartes de prsence des diffrentes espces : Cartes gographiques par espce prsentant un cumul historique des populations. Ce traitement peut tre demand par un adhrent. Cartes des observations ralises par chaque observateur. Ce traitement peut tre demand par un salari uniquement.
Ces cartes de prsence des oiseaux sont gnres par DataBirds et accessibles soit par le Web, soit par demande via un courrier lectronique ou postal.
170
83. Effectuez la premire tape de la mthode.
Lobjectif de cette tape est de produire le diagramme de cas dutilisation du niveau besoin. Nous identions deux acteurs, les adhrents et les salaris. Il ny a pas de relation dhritage entre ces acteurs, car rien noblige un salari tre aussi adhrent de lassociation. Les cas dutilisation associs ladhrent sont la ralisation dune observation (la saisie des informations relatives lobservation) et lobtention de la carte gographique relative une espce. Les cas dutilisation associs au salari sont la validation dune observation et lobtention de la carte des observations dun adhrent. Lapplication doit aussi permettre la suppression des observations qui nont pas t valides, mais cette fonctionnalit ntant relie aucun acteur, elle doit tre effectue automatiquement une fois par semaine. Etant donn que les cas dutilisation reprsentent les fonctionnalits offertes par lapplication son environnement, cette fonctionnalit de suppression des observations ne sera pas reprsente au niveau besoin. La gure 46 reprsente le diagramme de cas dutilisation du niveau besoin de lapplication DataBirds.
Figure 46
Diagramme de cas dutilisation de lapplication DataBirds
DataBirds
Raliser une observation
Obtenir une carte gographique Adhrent
Valider une observation
Salari
Obtenir une carte des observations
84. Effectuez la deuxime tape de la mthode (niveau besoin comportement).
Lobjectif de cette tape est de produire un diagramme de squence nominal par cas dutilisation ainsi quun diagramme de squence pour chaque erreur possible.
171
Pour le fonctionnement nominal du cas dutilisation Raliser une observation, nous considrons que ladhrent Jean ralise lobservation quil a faite sur trois merles Paris, le 1er juillet 2006, 12 heures. Le message raliserObservation() est envoy lapplication DataBirds, qui cre lobjet obs1 de type Observation. Linteraction illustre la gure 47 reprsente cette excution.
db:DataBirds Jean:Adhrent raliserObservation ("merle",3,"paris" , "01/07/06" , "12h00" , "Jean") cration obs1:Observation
Figure 47
Interaction reprsentant la ralisation dune observation
Pour un fonctionnement soulevant une erreur du cas dutilisation Raliser une observation , nous considrons le cas o ladhrent oublie de donner le nom de lobservateur. Dans ce cas, lapplication DataBirds doit signaler une erreur. Ce fonctionnement est reprsent par linteraction illustre la gure 48.
Figure 48
Interaction reprsentant la ralisation dune observation levant une erreur

Jean:Adhrent
db:DataBirds
raliserObservation ("dauphin",3,"paris" , "01/07/06" , "12h00" , "")
erreur : nom de l'observateur non saisi
172
Nous considrons maintenant le fonctionnement nominal du cas dutilisation Valider une observation . Un salari demande lapplication de valider une observation, et cette dernire lui rpond que tout est correct. Linteraction illustre la gure 49 reprsente ce fonctionnement.
Figure 49
Interaction reprsentant la validation dune observation

Pierre:Salari validerObservation (obs1)
db:DataBirds
ok
Nous navons prsent ici quune petite partie du diagramme de squence produire. Ce dernier doit contenir un diagramme pour le fonctionnement nominal de chaque cas dutilisation et un ou plusieurs diagrammes pour chaque fonctionnement erron. Pour assurer la cohrence entre les parties fonctionnelle, comportementale et structurelle, nous rappelons que les interactions doivent faire apparatre les acteurs identis ltape 1 et les classes qui seront utilises ltape 3.
85. Effectuez la troisime tape de la mthode.
Lobjectif de cette tape est de produire un diagramme de classes reprsentant les donnes spcies dans la description de lapplication. Les interactions que nous avons donnes en solutions de la question prcdente font apparatre les classes DataBirds et Observation. Nous introduisons la classe Adhrent, car lapplication doit pouvoir vrier que les observations sont faites par des adhrents. Les oprations associes aux cas dutilisation sont des oprations de la classe DataBirds. Les attributs de la classe Observation permettent de stocker toutes les caractristiques dune observation. Nous avons introduit deux boolens. Le boolen aValider est vrai lorsque lobservation na pas encore t valide par un salari. Lorsque ce boolen est vrai, il faut regarder le boolen valid pour savoir si lobservation est effectivement valide. Les classes DataBirds et Observation sont associes, car plusieurs observations sont gres par lapplication. De la mme faon, nous reprsentons le fait que plusieurs adhrents peuvent tre identis. La gure 50 reprsente le diagramme de classes obtenu.
173
Observation -espce:string -nombreIndividus:integer -lieu:string -date:string -heure:string -aValider:boolean -valide:boolean -observateurs:string[*]
observation *
DataBirds +raliserObservation() +validerObservation() +obtenirCarteGographique () +obtenirCarteObservation()
Adhrent -nom:string -prnom:string
adhrent *
Figure 50
Classes de lapplication DataBirds au niveau besoin
86. Effectuez la quatrime tape de la mthode.
Lobjectif de cette tape est de produire la liste des composants du systme et un diagramme de cas dutilisation par composant. Nous dcomposons notre systme en deux composants : le gestionnaire des observations et le gestionnaire des cartes. Le gestionnaire des observations soccupe de la cration, de la validation et de la suppression des observations. tant donn que nous sommes au niveau conceptuel, nous reprsentons cette fois la suppression des observations. Ce composant est reli aux acteurs Adhrent et Salari, qui sont concerns par la cration et la validation des observations. Il est aussi reli la base des adhrents, qui est un composant externe lapplication. Dans le descriptif de lapplication, aucune information nest donne sur la gestion des adhrents. Nous savons juste quil est ncessaire davoir accs une base des adhrents. Il sagit donc dun composant externe lapplication DataBirds. La gure 51 reprsente le diagramme de cas dutilisation du composant de gestion des observations.
174
Gestion des observations
Cration Observation Adhrent Suppression Observation
Valider Observation Base des adhrents
Salari
Figure 51
Diagramme de cas dutilisation du composant Gestion des observations
Le gestionnaire de cartes soccupe de la construction des diffrentes cartes que peuvent demander les acteurs. Il contient deux cas dutilisation, la construction des cartes gographiques et celle des cartes dobservation. Ce composant est reli aux acteurs Adhrent et Salari, car ils ont chacun accs un des cas dutilisation quil contient. Il est aussi reli une base de donnes des observations, car il en a besoin pour produire les cartes demandes. Cette base de donnes est en fait produite par le composant de gestion des observations, mais comme il nest pas possible dtablir des liens entre composants, nous devons le reprsenter par un acteur. Notons que lacteur BDObservation nest pas une personne physique, ce qui ne pose aucun problme puisque nous sommes au niveau conceptuel. La gure 52 reprsente le diagramme de cas dutilisation du composant de gestion des cartes. Il ne faut pas oublier de prciser les relations de rsolution entre les cas dutilisation du niveau danalyse et ceux des composants. Dans notre cas, cette tche est assez simple : Le cas dutilisation Raliser une observation est rsolu par le cas dutilisation Cration Observation . Le cas dutilisation Obtenir une carte gographique est rsolu par le cas dutilisation Construire Carte gographique . Le cas dutilisation Valider une observation est rsolu par le cas dutilisation Valider Observation . Le cas dutilisation Obtenir une carte des observations est rsolu par le cas dutilisation Construire Carte observations .
87. Effectuez la cinquime tape de la mthode.
Lobjectif de cette tape est de produire un diagramme de squence nominal par cas dutilisation, ainsi quun diagramme de squence pour chaque erreur possible.
175
Gestion des cartes
Adhrent
Construire Carte gographique
Construire Carte observations
BDObservation
Salari
Figure 52
Diagramme de cas dutilisation du composant de gestion des cartes
Nous reprenons le cas dutilisation qui consiste valider une observation. Cette fois, comme nous sommes au niveau conceptuel, nous devons faire apparatre les diffrentes tapes de la validation : la vrication que les observateurs sont bien des adhrents (ce qui ncessite un accs la base de donnes des adhrents) et la vrication que lespce observe est bien rpertorie dans le territoire concern. La gure 53 reprsente linteraction associe ce cas dutilisation.
db:DataBirds Pierre:Salari validerObservation (obs1) adhrent("Jean") oui db_adhrent:Base des adhrents
vrifierEspce("merle")
connue ok
Figure 53
Interaction au niveau conceptuel reprsentant la validation dune observation
Nous navons prsent ici quune petite partie du diagramme de squence produire. Ce dernier doit en effet contenir un diagramme pour le fonctionnement
176
nominal de chaque cas dutilisation et un ou plusieurs diagrammes pour chaque fonctionnement erron. Pour assurer la cohrence entre les parties fonctionnelle, comportementale et structurelle, nous rappelons que les interactions doivent faire apparatre les acteurs identis ltape 4 et les classes utilises ltape 6.
88. Effectuez la sixime tape de la mthode.
Lobjectif de cette tape est de produire les classes des composants. Toutes les classes dun mme composant sont regroupes dans un mme package. Il est important de prciser aussi les relations de dpendance entre les composants. Le composant Gestion des Observation est reprsent par le package gestionObservation. Il contient les classes Espce et Observation, qui reprsentent respectivement les espces visibles sur le territoire et les observations faites par les adhrents. Le composant contient aussi la classe BaseDeDonnes, qui contient (relation de composition) lensemble des espces et lensemble des observations. Cette classe possde aussi les oprations qui seront utilises par lenvironnement du composant (ajouterObservation(), validerObservation(), supprimerObservationsNonValides()). Le composant Gestion des cartes est reprsent par le package gestionCartes. Nous avons fait le choix de crer la classe Carte, qui est une classe abstraite. Notre intention est de stocker dans une mmoire cache nimporte quelle carte (gographique ou observation) dj construite. Les classes CarteGographique et CarteObservation hritent donc de cette classe abstraite. Celles-ci sont associes aux classes du composant Gestion des Observation dont elles ont besoin. La classe GestionnaireCarte contient lensemble des cartes dj cres et possde les oprations qui seront utilises par lenvironnement du composant (construireCarteGeographique(), construireCarteObservation(), rechercheCarte()). Soulignons que cette spcication de la structure des composants nest pas complte. Nous la jugeons cependant sufsante pour notre propos.
89. Effectuez la septime tape de la mthode.
Lobjectif de cette tape est de produire les classes des composants en intgrant les classes de la plate-forme dexcution. partir de la spcication des composants faite la question prcdente, il suft de remplacer les associations de multiplicit * par des liens vers la classe ArrayList. Ces modications sont reprsentes la gure 55. Les liens dabstraction entre les niveaux conceptuel et physique sont relativement triviaux car ils apparaissent entre les packages de mme nom. Pour ce qui est des liens dabstraction pour les associations multiplicit *, il faut refaire ce qui a t prsent au TD8.
90. Effectuez la huitime tape de la mthode sur une seule classe.
Lobjectif de cette tape est de produire les cas de test abstraits. titre dexemple, nous pouvons spcier les cas de test abstrait de la classe BaseDeDonnes et crire les tests abstraits concernant la validation dune observation. Une
177
gestionObservation
BaseDeDonnes -territoire:string +ajouterObservation() +validerObservation() +supprimerObservationsNonValides() 1 1 espce * Espce -nom:string espce 1
observation
Observation -id:integer -espce:string -nbIndividus:integer -date:string -heure:string -observateurs:string[*] -aValider:boolean -valide:boolean
* observation
gestionCartes
GestionnaireCarte carteEnCache +rechercheCarte() +construireCarteGographique () +construireCarteObservation() 1 * Carte -id:integer
CarteGographique
CarteObservation -adhrent:string
Figure 54
Classes des composants de gestion des observations et de gestion des cartes
178
carteEnCache 0..1 espce
ArrayList
0..1 observation
0..1 observation
0..1
gestionObservation
BaseDeDonnes -territoire:string +ajouterObservation() +validerObservation() +supprimerObservationsNonValides() Espce -nom:string espce 1
Observation -id:integer -espce:string -nbIndividus:integer -date:string -heure:string -observateurs:string[*] -aValider:boolean -valide:boolean
gestionCartes
GestionnaireCarte Carte +rechercheCarte() +construireCarteGographique () +construireCarteObservation() -id:integer
CarteGographique
CarteObservation -adhrent:string
Figure 55
Classes des composants au niveau physique
179
faute ventuelle serait de valider une observation portant sur une espce nappartenant pas au territoire. Un cas de test visant rvler une telle faute est spci la gure 56.
testeur: cration db:BaseDeDonnes ajouterObservation("dauphin",3,"paris" , "01/07/06" , "12h00" , "jean")
obs1 validerObservation (obs1)
Rsultat attendu : l'observation ne doit pas tre valide
Figure 56
Diagramme de cas de test de la classe BaseDeDonnes
91. Effectuez la neuvime tape de la mthode.
Lobjectif de cette tape est de produire le diagramme de cas dutilisation reprsentant les fonctionnalits offertes par les composants mais au niveau physique. Cependant, cette tape nest ncessaire que si certaines fonctionnalits sont ralises par la plate-forme dexcution. Cela permet en ce cas de faire apparatre les fonctionnalits directement offertes par la plate-forme et celles quil faudra dvelopper. tant donn que, dans notre cas, aucune fonctionnalit nest directement offerte par la plate-forme, cette tape nest pas ncessaire.
Annexes
1
Code dun carnet dadresses
/---------------------------------------------------------------------------------/ package repertoire; public class MyAssistant { public static void main(String[] args) { UIRepertoire ihm = new UIRepertoire(); } } /---------------------------------------------------------------------------------/ package repertoire; import java.awt.event.*; import javax.swing.*; import javax.swing.event.*; public class UIRepertoire extends JFrame { Repertoire theRepertoire; UIMenuActionListener menuListener; JMenuBar menu_barre; JMenu repertoire_menu, fonction_menu, aide_menu; JMenuItem repertoire_menu_ouvrir, repertoire_menu_enregistrer, repertoire_menu_enregistrersous, repertoire_menu_nouveau, fonction_menu_ajouterPersonne, fonction_menu_rechercherPersonne, aide_menu_item; JSplitPane splitPane; JList repertoireView;
184
UIPersonne uipersonne; public Repertoire getTheRepertoire() { return theRepertoire; } public void setTheRepertoire(Repertoire theRepertoire) { this.theRepertoire = theRepertoire; refreshUIRepertoire(); } public UIRepertoire() { super("Mon Repertoire"); menuListener = new UIMenuActionListener(this); WindowListener l = new WindowAdapter() { public void windowClosing(WindowEvent e) { System.exit(0); } public void windowClosed(WindowEvent e) { System.exit(0); } }; addWindowListener(l); init(); } public UIRepertoire(Repertoire rep) { super("Mon Repertoire"); theRepertoire = rep; menuListener = new UIMenuActionListener(this); WindowListener l = new WindowAdapter() { public void windowClosing(WindowEvent e) { System.exit(0); } public void windowClosed(WindowEvent e) { System.exit(0); } }; addWindowListener(l); init(); refreshUIRepertoire(); } void init() { //Barre de Menu menu_barre = new JMenuBar(); setJMenuBar(menu_barre); // Menu FICHIER repertoire_menu = new JMenu("Fichier"); menu_barre.add(repertoire_menu); repertoire_menu_nouveau = new JMenuItem("Nouveau");
Code dun carnet dadresses ANNEXE 1
185
repertoire_menu.add(repertoire_menu_nouveau); repertoire_menu_nouveau.addActionListener(menuListener); repertoire_menu_ouvrir = new JMenuItem("Ouvrir"); repertoire_menu.add(repertoire_menu_ouvrir); repertoire_menu_ouvrir.addActionListener(menuListener); repertoire_menu_enregistrer = new JMenuItem("Enregistrer"); repertoire_menu.add(repertoire_menu_enregistrer); repertoire_menu_enregistrer.addActionListener(menuListener); //fichier_menu_enregistrer.setMnemonic(KeyEvent.VK_S); repertoire_menu_enregistrersous = new JMenuItem("Enregistrer Sous"); repertoire_menu.add(repertoire_menu_enregistrersous); repertoire_menu_enregistrersous.addActionListener(menuListener); // Menu FONCTION fonction_menu = new JMenu("Organisation"); menu_barre.add(fonction_menu); fonction_menu_ajouterPersonne = new JMenuItem("Ajouter Nouvelle Personne"); fonction_menu.add(fonction_menu_ajouterPersonne); fonction_menu_ajouterPersonne.addActionListener(menuListener); fonction_menu_rechercherPersonne = new JMenuItem("Rechercher Personne(s)"); fonction_menu.add(fonction_menu_rechercherPersonne); fonction_menu_rechercherPersonne.addActionListener(menuListener); // Menu AIDE aide_menu = new JMenu("Aide"); menu_barre.add(aide_menu); aide_menu_item = new JMenuItem("A Propos"); aide_menu_item.addActionListener(menuListener); aide_menu.add(aide_menu_item); //Mettre un SplitPane splitPane = new JSplitPane(JSplitPane.HORIZONTAL_SPLIT); getContentPane().add(splitPane); setVisible(true); pack(); } public void refreshUIRepertoire() { // Mettre la JList gauche repertoireView = new JList(theRepertoire.listerPersonnes()); repertoireView.addListSelectionListener(new ListSelectionListener() { public void valueChanged(ListSelectionEvent e) { System.out.println("Ok"); Personne p = (Personne) repertoireView.getSelectedValue(); uipersonne.setPersonne(p); } }); splitPane.setLeftComponent(new JScrollPane(repertoireView));
186
//Test droite if (theRepertoire.listerPersonnes().length!=0) { uipersonne = new UIPersonne(theRepertoire.listerPersonnes()[0]); splitPane.setRightComponent(uipersonne); } } } /---------------------------------------------------------------------------------/ package repertoire; import java.awt.GridLayout; import java.awt.event.*; import javax.swing.*; public class UIPersonne extends JPanel { Personne personne; JTextField nomTF, prenomTF, telMaisonTF, telPortTF, telBurTF, faxTF, titreTF, socTF, addTF, mailTF; public UIPersonne() { super(); init(); } public UIPersonne(Personne p) { super(); personne = p; init(); } public Personne getPersonne() { return personne; } public void setPersonne(Personne personne) { this.personne = personne; prenomTF.setText(personne.getPrenom()); nomTF.setText(personne.getNom()); telBurTF.setText(personne.getTelephoneBureau()); telMaisonTF.setText(personne.getTelephoneMaison()); telPortTF.setText(personne.getTelephonePortable()); faxTF.setText(personne.getFax()); titreTF.setText(personne.getTitre());
187
socTF.setText(personne.getSociete()); //Adresse mailTF.setText(personne.getMail()); } public void init() { this.setLayout(new GridLayout(0, 2)); add(new JLabel("nom")); nomTF = new JTextField(""); add(nomTF); add(new JLabel("prenom")); prenomTF = new JTextField(""); add(prenomTF); add(new JLabel("telephone maison")); telMaisonTF = new JTextField(""); add(telMaisonTF); add(new JLabel("telephone portable")); telPortTF = new JTextField(""); add(telPortTF); add(new JLabel("telephone bureau")); telBurTF = new JTextField(""); add(telBurTF); add(new JLabel("fax")); faxTF = new JTextField(""); add(faxTF); add(new JLabel("titre")); titreTF = new JTextField(""); add(titreTF); add(new JLabel("socit")); socTF = new JTextField(""); add(socTF); add(new JLabel("adresse")); addTF = new JTextField(""); add(addTF); add(new JLabel("mail")); mailTF = new JTextField(""); add(mailTF); JButton save = new JButton("Save"); save.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { personne.setPrenom(prenomTF.getText()); personne.setNom(nomTF.getText()); personne.setTelephoneBureau(telBurTF.getText()); personne.setTelephoneMaison(telMaisonTF.getText()); personne.setTelephonePortable(telPortTF.getText()); personne.setFax(faxTF.getText()); personne.setTitre(titreTF.getText()); personne.setSociete(socTF.getText()); //personne.setAdresse(addTF.getText()); personne.setMail(mailTF.getText()); } });
188
add(save); JButton cancel = new JButton("Cancel"); cancel.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { prenomTF.setText(personne.getPrenom()); nomTF.setText(personne.getNom()); telBurTF.setText(personne.getTelephoneBureau()); telMaisonTF.setText(personne.getTelephoneMaison()); telPortTF.setText(personne.getTelephonePortable()); faxTF.setText(personne.getFax()); titreTF.setText(personne.getTitre()); socTF.setText(personne.getSociete()); //Adresse mailTF.setText(personne.getMail()); } }); add(cancel); } } /---------------------------------------------------------------------------------/ package repertoire; import java.awt.event.*; import javax.swing.JMenuItem; public class UIMenuActionListener implements ActionListener { UIRepertoire uirep; public UIMenuActionListener(UIRepertoire uirep) { super(); this.uirep = uirep; } public void actionPerformed(ActionEvent ev) { JMenuItem test = (JMenuItem) ev.getSource(); if (test.getText() == "A Propos") System.out.println("Aide"); else if (test.getText() == "Rechercher Personne(s)") { System.out.println("LOAD "); } else if (test.getText() == "Ajouter Nouvelle Personne") { System.out.println("Ajouter Nouvelle Personne "); Personne p = new Personne(); uirep.getTheRepertoire().ajouterPersonne(p); uirep.refreshUIRepertoire(); } else if (test.getText() == "Rechercher Personne(s)") { System.out.println("LOAD "); } else if (test.getText() == "Nouveau") { System.out.println("Nouveau ");
189
uirep.setTheRepertoire(new Repertoire()); } else if (test.getText() == "Enregistrer Sous") { System.out.println("LOAD "); } else if (test.getText() == "Enregistrer") { System.out.println("LOAD "); } else if (test.getText() == "Ouvrir") { System.out.println("LOAD "); } } } /---------------------------------------------------------------------------------/ package repertoire; public class Adresse { String pays; String region; String codePostal; String ville; String rue; public String getCodePostal() { return codePostal; } public void setCodePostal(String codePostal) { this.codePostal = codePostal; } public String getPays() { return pays; } public void setPays(String pays) { this.pays = pays; } public String getRegion() { return region; } public void setRegion(String region) { this.region = region; } public String getRue() { return rue; }
190
public void setRue(String rue) { this.rue = rue; } public String getVille() { return ville; } public void setVille(String ville) { this.ville = ville; } } /---------------------------------------------------------------------------------/ package repertoire; public class Personne { String nom; String prenom; String telephoneMaison; String telephonePortable; String telephoneBureau; String fax; String titre; String societe; Adresse adresse; String mail; public Adresse getAdresse() { return adresse; } public void setAdresse(Adresse adresse) { this.adresse = adresse; } public String getFax() { return fax; } public void setFax(String fax) { this.fax = fax; } public String getMail() { return mail; } public void setMail(String mail) { this.mail = mail; }
191
public String getNom() { return nom; } public void setNom(String nom) { this.nom = nom; } public String getPrenom() { return prenom; } public void setPrenom(String prenom) { this.prenom = prenom; } public String getSociete() { return societe; } public void setSociete(String societe) { this.societe = societe; } public String getTelephoneBureau() { return telephoneBureau; } public void setTelephoneBureau(String telephoneBureau) { this.telephoneBureau = telephoneBureau; } public String getTelephoneMaison() { return telephoneMaison; } public void setTelephoneMaison(String telephoneMaison) { this.telephoneMaison = telephoneMaison; } public String getTelephonePortable() { return telephonePortable; } public void setTelephonePortable(String telephonePortable) { this.telephonePortable = telephonePortable; } public String getTitre() { return titre; }
192
public void setTitre(String titre) { this.titre = titre; } public String toString() { return nom+" "+prenom; } } /---------------------------------------------------------------------------------/ package repertoire; import java.util.Iterator; import java.util.ArrayList; public class Repertoire { ArrayList personnes; public void ajouterPersonne(Personne p) { personnes.add(p); } public void supprimerPersonne(Personne p) { personnes.remove(p); } public Personne[] rechercherPersonnesParNom(String nom) { ArrayList success = new ArrayList(); for (Iterator it = personnes.iterator() ; it.hasNext() ;) { Personne current = (Personne) it.next(); if (current.getNom().compareTo(nom)==0) success.add(current); } Personne[] res = new Personne[0]; return (Personne[]) success.toArray(res); } public Personne[] listerPersonnes() { Personne[] res = new Personne[0]; return (Personne[]) personnes.toArray(res); } public Repertoire() { personnes = new ArrayList(); } }
2
Exemple de partiel
Nous proposons ici un partiel donn, le 31 mars 2005, une promotion de quatre-vingtdix tudiants de L3 de lUniversit Pierre et Marie Curie. Sa dure tait de deux heures, et tous documents taient autoriss. Chacune des quatre question de cours est note sur 1 point et chacun des huit exercices sur 2 points, soit un total de vingt points. Cette annexe est particulirement destine aux enseignants dsireux de transmettre les principes de base de lapproche UML pour le dveloppeur des tudiants de L3 (bac + 3).
Questions de cours (4 points)

1. Dnissez les approches Model Driven, Code Driven et Round Trip.
Voir, au chapitre 5, la section Approches envisageables .

2. Dnissez les diffrents cas permettant didentier des dpendances entre deux classes.
Voir, au chapitre 4, la section Quest-ce quune dpendance ? .

3. Lhritage multiple entre classes UML est-il possible ? Que signie-t-il pour les objets instances ?
Oui. Les instances appartiennent aux deux ensembles dobjets dnis par les classes (intersection). Voir, au chapitre 2, la section Hritage entre classes .
4. Est-il possible de gnrer une application C++ partir dun modle UML ?
Oui, tout comme il est possible de gnrer du Java. Les limites sont sensiblement les mmes, cest--dire quil faut recopier les lignes de code dans les modles et donc faire du recopiage de code.
194
Exercices (16 points)

De jeunes tudiants de Paris VI ont dvelopp une application permettant de faire calculer des robots des itinraires dans des zones gographiques jonches dobstacles. La gure 1 illustre une zone gographique compose de sept obstacles (reprsents par des disques noirs) avec un robot (reprsent par un triangle) devant calculer les itinraires permettant daccder la cible (reprsente par une toile).
Figure 1
Zone gographique
Il a t demand aux tudiants de commencer la ralisation de lapplication par llaboration dun modle UML. Le diagramme de la gure 2 reprsente toutes les classes du modle UML ralis par les tudiants. 5. Commentez le diagramme de classes fourni par les tudiants, et expliquez la signication de chacune des classes vis--vis de la problmatique nonce dans le sujet. Prsentez chacun des attributs et chacune des associations.
La classe ZoneGographique reprsente une zone gographique sous forme de grille deux dimensions. Lattribut nbColonnes correspond au nombre de colonnes de la grille, et lattribut nbLignes au nombre de lignes de la grille. Une zone gographique contient des obstacles diffrentes positions dans la grille (association obstacle), ainsi que des robots (association habitant). La classe Position reprsente une position dans la grille. Lattribut colonne correspond au numro de la colonne de la position, et lattribut ligne au numro de la ligne de la position. Nous pouvons prendre comme convention que la position 0,0 correspond au coin suprieur gauche de la grille (cela nest pas spci dans lnonc du sujet). La classe Robot reprsente un robot. Un robot peut se promener dans la grille an de calculer un itinraire. Les attributs PositionLigne et PositionColonne reprsentent la position actuelle du robot (il aurait dailleurs t possible de ne pas mettre ces attributs et de reprsenter la position du robot par une association vers la classe Position).
Exemple de partiel ANNEXE 2

Figure 2
195
Classes de lapplication
ZoneGographique +nom:string +nbColonnes:integer +nbLignes:integer
habitant *
Robot +positionColonne:string +positionLigne:string +atteindrePosition()
dpart obstacle Position *
chemin *
Itinraire
+colonne:string +ligne:string
arrive
La classe Itinraire reprsente un itinraire calcul par un robot. Un itinraire a une position de dpart (association dpart), une position darrive (association arrive) et un ensemble de positions dnissant le chemin (association chemin). Aprs avoir ralis leur modle UML, les tudiants ont utilis la gnration de code vers Java. Ils ont ensuite modi le code correspondant la classe Robot an de raliser le traitement de la mthode atteindrePosition. Voici les modications quils ont d effectuer sur la classe Robot : Les tudiants ont ajout un attribut nomm zoneDuRobot, dont le type est ZoneGeographique. Les tudiants ont ajout lopration presenceObstacle, dont le code est le suivant :
public boolean presenceObstacle(int x , int y) { for (int i=0 ; i < zoneDuRobot.obstacle.size() ; i++) { Obstacle obs= Obstacle)zoneDuRobot.obstacle.elementAt(i); if ((obs.getColonne() == x) && (pos.getLigne()== y)) return true; } return false;
Les tudiants ont dvelopp le code de lopration atteindrePosition, dont le code est le suivant (il nest pas ncessaire de comprendre ce code pour rpondre aux questions de lexamen) :
public Itinraire atteindrePosition(Position lieux){ Itinraire res = new Itinraire(); int x = positionColonne; int y = positionLigne;
196
int i=0; while (x!=lieux.getColonne() && y!=lieux.getLigne()) { Position pos = new Position(); //A droite int droite = x +1 ; if (droite < zoneDuRobot.getNbColonnes() && !presenceObstacle(droite,y)) { pos.setColonne(droite); pos.setLigne(y); } else { // En bas int bas = y+1; if (bas <zoneDuRobot.getNbLignes() && ! presenceObstacle(x , bas)) { pos.setColonne(x); pos.setLigne(bas); } else { //gauche int gauche = x-1; if (gauche>0 && ! presenceObstacle(gauche , y)) { pos.setColonne(gauche); pos.setLigne(y); } } res.setChemin(i++ , pos); y = pos.getLigne(); x = pos.getColonne(); } return new Itinraire(); }
6. Faites lupdate du modle UML.
Il est ncessaire dajouter lassociation zoneDuRobot et lopration prsenceObstacle(). Le code de lopration atteindrePosition doit tre ajout en note. La gure 3 reprsente la partie modie du diagramme de classes.
Figure 3
Classes ZoneGographique et Robot aprs update
habitant
ZoneGographique +nom:string +nbColonnes:integer +nbLignes:integer
Robot +positionColonne:string +positionLigne:string +atteindrePosition() +prsenceObstacle()
zoneDuRobot
0..1
197
7. Construisez un diagramme ne prsentant que les dpendances entre les classes de lapplication.
Il suft de suivre les rgles tablies au chapitre 4. La gure 4 prsente les dpendances entre les classes.
Figure 4
Dpendances entre les classes
ZoneGographique
Robot
Position
Itinraire
8. Est-il possible de dplacer lopration presenceObstacle dans une autre classe que la classe Robot ? Est-ce judicieux ?
Oui, car la classe responsable de cette opration est la classe ZoneGographique. Cest elle qui contient toutes les informations pour pouvoir raliser le traitement. Cest judicieux, car il y a fort parier que dautres classes que celle du robot auront besoin de savoir si une position est occupe par un obstacle ou non.
9. Lassociation entre les classes ZoneGographique et Robot (dont le nom du crochet de lassociation est habitant) est-elle ncessaire pour lapplication ? Si oui, pourquoi ? Si non, peut-on la supprimer ?
Non. Dans cette application, la zone gographique na jamais besoin de savoir quels sont les robots prsents (habitant). Nous pouvons donc la supprimer ou la rendre non navigable.
10. Aprs avoir excut plusieurs fois lapplication, il apparat que le code de lopration atteindrePosition nest pas correct. Il serait mme intressant de pouvoir changer facilement ce code an de tester plusieurs stratgies de calcul ditinraire. Pour atteindre cet objectif, lenseignant responsable du projet propose aux tudiants dappliquer le patron de conception Stratgie. Appliquez ce patron sur la classe Robot et lopration atteindrePosition en dnissant les stratgies VersLaDroite, VersLaGauche et Alatoire. Expliquez lintrt de ce patron.
Le robot est lutilisateur, et lalgorithme est lopration atteindrePosition(). Nous ajoutons donc dans la classe Robot lopration calculerItinraire(), qui utilise lalgorithme. Linterface Algorithme du patron est reprsente par linterface CalculItinraire. Les diffrentes stratgies qui ralisent cette interface sont reprsentes par les classes VersLaDroite, VersLaGauche et Alatoire. La gure 5 reprsente lapplication de ce patron.
198
Figure 5
Application du patron de conception Stratgie
Robot +positionColonne:string +positionLigne:string +prsenceObstacle() +calculerItinraire()
algorithme 1
interface CalculItinraire +atteindrePosition()
VersLaDroite +atteindrePosition()
VersLaGauche +atteindrePosition()
Alatoire +atteindrePosition()
11. Positionnez les classes relatives la reprsentation gographique dans un package et les classes relatives au calcul de litinraire dans un autre package.
Nous plaons dans le package representationGeographique les classes ZoneGographique et Position, qui sont les seules reprsenter effectivement une zone gographique. Dans le package calculItinraire, nous plaons toutes les autres classes. La gure 6 reprsente ces deux packages.
representationGeographique
0..1 ZoneGographique zoneDuRobot Robot 1
calculItineraire
algorithme interface CalculItinraire
obstacle Itinraire VersLaDroite VersLaGauche Alatoire
Position
Figure 6
Dcoupe en package de lapplication
12. Dnissez un ensemble dalgorithmes, et encapsulez-les dans des classes an de les rendre interchangeables.
Il existe souvent plusieurs algorithmes qui ralisent plus ou moins un mme traitement (les diffrents algorithmes de tri, par exemple). Les utilisateurs de ces algorithmes doivent inclure tous les algorithmes sils veulent pouvoir changer dalgorithme en cours dexcution. Ils deviennent alors trs gros et difcilement maintenables. De plus, certains algorithmes ne seront pas forcment utiliss. Il nest alors pas intressant dinclure le code des ces algorithmes. Pour nir, inclure tous les algorithmes dans les applications qui les utilisent fait quil est difcile dajouter de nouveaux algorithmes.
199
La solution consiste dnir une interface dnissant la signature de lexcution de lalgorithme puis dnir une classe concrte par algorithme diffrent, comme illustr la gure 7.
Utilisateur +operationUtilisantLAlgorithme() algorithme 1 interface Algorithme +executerAlgorithme()
algorithme.executerAlgorithme()
StrategieA +executerAlgorithme()
StrategieB +executerAlgorithme()
//Code de la stratgie A
//Code de la stratgie B
Figure 7
Patron de conception Stratgie
Index
A acteur 99, 166 concept avanc 104 hritage 104 agrgation 20 application oriente objet 13 fonctionnalits 97 approche Code Driven 56 Model Driven 56 Round Trip 56 association 28, 128, 197 de composition 20 entre classes 19 navigable 20, 137 C cahier des charges 110 cas dutilisation 98, 166 concepts avancs 101 extend 103 hritage 104 include 102 interactions 101 cas de test abstrait 79, 158, 176 criture partir dun modle UML 80 excutable 79, 158 et interactions 81 classe 14 abstraite 21 anonyme 125 association 19, 197 navigable 137 associations 128 concrte 199 dpendance 40, 142, 193 hritage 16, 130 multiple 148, 193 intersection 193 opration 15 package 17, 132, 198 proprit 15, 128 superclasse 45 visibilit 22 code 4 et fonctionnalits 4 et maintenance 4 gnration de 51, 59, 146 composition 20 construction dapplications 1 documents raliser 6 Java partir dun modle UML 51 rle des modles 7 du code 4 correspondance Java vers UML 32 UML vers Java 146 cycle de dpendances 142 D dpendances cycles de 41 casser 43 identier les 39 dveloppement avec UML 1, 27, 39, 51, 63, 77, 87, 97, 109, 121, 169 diagramme de cas dutilisation 97, 166 acteurs 166 concepts avancs 101 niveau besoin 170 niveau physique 179 par composant 173 de classes 13, 127, 132, 194 de squence 63, 151 conceptuel 163 concret 165 de test 77, 81, 85 nominal par cas dutilisation 170 documentation 6, 125 E extend 103 G gnration de code 51, 59, 146, 164 et interactions 70 H hritage 104 entre classes 16 multiple 148, 193 I include 102, 167 indpendance lgard des platesformes techniques 111 indirection 43 interaction de test 81 et gnration de code 70 fragments d 72 limites intrinsques 72 messages 66 objets 64 interface 14, 199
202
opration 15 proprit 15 J Java rgles de correspondance vers UML 136 JUnit 82 M message 65 mthode de dveloppement 114 UML pour le dveloppeur 115 modle 7 100 % UML 161 concept 9 conceptuel 94 dnition 7 et code 8 physique 94 vues sur une application 7 multiplicit 21 N navigabilit 131 note 18, 136 O objet 64 et classe 68 mtier 161 non typ 153, 168 typ dans une interaction 68 opration 15 de classe 22
de productivit 39, 45, 47 direction des paramtres 28 note 136 traitement 29 visibilit 22 P package 17, 132, 198 dpendance 42 import 28 paradigme orient objet 13, 63 patron de conception 39, 45, 141 et modles conceptuels 161 Observer 45, 144, 162 Singleton 162 Stratgie 197 plate-forme dexcution 87, 89, 94, 161, 179 proprit 15 de classe 22 multiplicit 21 visibilit 22 R rgles de correspondance Java vers UML 32, 136 UML vers Java 51, 146 rtroconception 39, 141 Reverse Engineering 27, 136 diagrammes faire aprs 35 gains offerts 35 intrt et limites 34 rgles de correspondance 32 rle 46 Round Trip 57
update 151 S smantiques UML et Java 27 superclasse 45 systme 99 T test 77, 158 abstrait 163 cas de test abstrait 79 excutable 79 dnitions 78 U UML productif ou prenne 88 vers Java 54, 146 update 60, 149, 196 V visibilit 22 vue comportementale 63 cohrence avec la vue structurelle 68 concepts 64 fonctionnelle 97 concepts lmentaires 98 structurelle 13, 31, 140 cohrence avec la vue comportementale 68 concepts 14
Xavier Blanc
Matre de confrences lUniversit Pierre et Marie Curie (Paris 6), Xavier Blanc est responsable de lenseignement des techniques de modlisation en 3e anne de licence et en master dinformatique. Ses recherches portent depuis 1998 sur lingnierie guide par les modles et il est le reprsentant du LIP6 (Laboratoire dinformatique de lUniversit Paris 6) lOMG. Il est galement auteur de MDA en action, paru chez le mme diteur.
Isabelle Mounier
Matre de confrences lUniversit Pierre et Marie Curie, Isabelle Mounier enseigne principalement les techniques de dveloppement dapplications en licence dinformatique. Ses activits de recherche ont dabord port sur la vrification de proprits temporelles de systmes informatiques modliss par des rseaux de Petri et elle sintresse aujourdhui aux aspects formels des langages de modlisation tels quUML. Un cours dinitiation UML conu pour les dveloppeurs et les tudiants en informatique La 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 rticences chez les dveloppeurs et dconcerte les tudiants, dont la formation reste axe principalement sur la programmation et qui mesurent mal les enjeux du formalisme UML. UML 2 pour les dveloppeurs prend le contre-pied de ces approches classiques. Louvrage montre comment articuler harmonieusement modlisation et programmation, en insistant sur les gains de productivit que permettent ces allers-retours entre les modles UML et le code. Chaque notion UML importante est introduite par un exemple et chaque chapitre se clt par une srie dexercices corrigs (90 au 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 prsents tant naturellement transposables dautres langages. Au sommaire
Pourquoi 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 Diagrammes de cas dutilisation Dveloppement avec UML Corrigs des exercices.
Code diteur : G12029 ISBN : 2-212-12029-X
Sur le site www.editions-eyrolles.com

Dialoguez avec les auteurs Tlchargez les modles et le code source des exemples du livre
16,90
782212 120295

UML 2 Pour Les Developpeurs

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

UML 2 Pour Les Developpeurs

Transféré par

Droits d'auteur :

Formats disponibles

Xavier Blanc Isabelle Mounier

avec la contribution de Cdric Besse

pour les pour les

UML pour les dveloppeurs

Une approche contre-pied

qui sadresse ce cours ?

Table des matires

III V VII VIII VIII IX

Un curieux besoin de modles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

UML pour les dveloppeurs

Synthse entre UML et les langages de programmation . . . . . . . . . . . . . . .

Rtroconception et patrons de conception . . . . . . . . . . . . . . . . . .

Table des matires

Diagrammes de squence de test . . . . . . . . . . . . . . . . . . . . . . . . . . .

Diagrammes de cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

97 97 97 98 100 101 101 104

Dveloppement avec UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

109 109 110 110

UML pour les dveloppeurs

Comment passer du quoi au comment ? . . . . . . . . . . . . . . . . . . . . . . . . . . .

111 114 115

Mthode de dveloppement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . La mthode UML pour le dveloppeur . . . . . . . . . . . . . . . . . . . . . . . . .

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

193 193 194 201

Simplication extrme de la ralisation dune application informatique

Avoir un logiciel pour crire un livre ou une lettre

UML pour les dveloppeurs

Un curieux besoin de modles CHAPITRE 1

Rutilisation Analyse Evolution

Impact Architecture Sparation du dveloppement Ralisation

Solution Mise en prproduction Maintenance

Test de monte en charge

UML pour les dveloppeurs

Un curieux besoin de modles CHAPITRE 1

Deuxime simplication de la ralisation dune application

Avoir un logiciel pour crire un livre ou une lettre

Code source de Word

UML pour les dveloppeurs

Documentation de la conception de lapplication Spcication des besoins

Un curieux besoin de modles CHAPITRE 1

UML pour les dveloppeurs

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

Modle dune application

Vue des donnes

Vue des utilisateurs

Un curieux besoin de modles CHAPITRE 1

UML pour les dveloppeurs

Un curieux besoin de modles CHAPITRE 1

TD1. Un curieux besoin de modles

Question 3 Question 4 Question 5 Question 6 Question 7 Question 8

Vue structurelle du modle UML

Paradigme orient objet

UML pour les dvelopperus

Reprsentation graphique dune classe

Diagrammes de classes CHAPITRE 2

Reprsentations graphiques dune interface

Reprsentation graphique dune relation de ralisation

Proprit (anciennement appele attribut) dune classe ou dune interface

Reprsentation graphique dune proprit dune classe

Personne nom : string

Opration dune classe ou dune interface

UML pour les dvelopperus

Reprsentation graphique dune opration dune classe

Personne nom : string getNom()