Corrige 1
Corrige 1
Corrige 1
Jean-Yves Didier
Diagrammes de collaboration 2.1 Lancement de la simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Passage au diagramme de s quence . . . . . . . . . . . . . . . . . . . . . . e 2.2 Mettre et prendre un objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagramme des classes 3.1 Discussion sur les sp cicit Java et le d veloppement de classes . . . . . . . . . . . e e e 3.1.1 Les constructeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Le verrouillage et d verrouillage du compartiment . . . . . . . . . . . . . . e Le diagramme de composants Le diagramme de d ploiement e
4 5
Situation Initiale
Le producteur et le consommateur : Un producteur produit des objets qui sont consomm s par un e consommateur . A une lointaine epoque, le consommateur pouvait demander directement lobjet au producteur. Toutefois, la l gislation actuelle, pour des raisons dhygi` ne, impose que le producteur e e ne soit plus en contact direct avec le consommateur. L change d objets se fait donc par un compare timent muni de deux trappes. Une trappe est destin au producteur, lautre au consommateur. Il ne e peut y avoir quune seule trappe ouverte en m me temps. Le producteur, son objet termin au bout e e dun temps plus ou moins long, ouvre la trappe et met lobjet dans le compartiment. Le consommateur, quant a lui, ouvre la trappe d` s quil peut pour voir si lobjet de sa convoitise se trouve dans le e ` compartiment. Nous nous proposons de simuler par un programme Java le comportement dun producteur et dun consommateur qui s changent des objets via un compartiment. An de simplier la simulation, nous e d cidons que le nombre dobjets echang s sera de 10. e e 1
Le producteur ainsi que le consommateur peuvent etre assimil s a des threads Java au comportee ` ment bien d termin . e e
1
1.1
Tout dabord, dans un tel cas d tude, il convient d num rer les acteurs ainsi que les objectifs e e e auquel doit r pondre le syst` me selon le point de vue des acteurs. Une premi` re vision de la situation e e e nous donne la liste dacteurs (personnes ou syst` mes intervenant dans le mod` les) suivants : e e Le producteur, Le consommateur, Le compartiment, Les objectifs que doit accomplir le syst` me sont les suivants (entre parenth` ses sont indiqu s les e e e acteurs impliqu s dans les objectifs) : e Mettre des objets dans le compartiment (producteur), Prendre des objets dans le compartiment (consommateur), Assurer la synchronisation (compartiment). ` Ces objectifs vont se transformer en cas dutilisation que lon pourra associer a chaque acteur. Pour ` ce qui est de la d pose ou de la prise dobjets, les cas dutilisation feront appel a la fonctionnalit de e e ` synchronisation lorsque cette derni` re sav` re n cessaire a utiliser (d pendance de type extend). Ceci e e e e ` aboutit a la r alisation du premier diagramme de cas dutilisation (Fig. 1). e
Toutefois, en raison de ce qui est propos , la mod lisation de la situation implique egalement le e e fait que celle-ci est une simulation de la situation initiale. Ceci implique egalement de simuler le producteur, le consommateur et le compartiment. Ceci am` ne a cr er un nouveau diagramme de cas e ` e dutilisation (Fig. 2 page suivante). Une fois le diagramme de cas dutilisation elabor , nous allons tracer les diagrammes dactivit s e e ` correspondants a chaque cas dutilisation mentionn s. e
mrio na ep m tC t oosA ace snrls as r d<nnryu uo nacabje i>nacabjM etr mo mriossttenrtih>epsstee uP m ep>edP d<rionortt rd etC m>ed mteled c as ttenoe n< ds u rn nx r ett e o m d< e les x
F IG . 1 Premier diagramme de cas dutilisation 2
1.3
Les sc narios de cas dutilisation peuvent etre d termin s en sappuyant sur les diagrammes dace e e tivit li s a la description de chaque cas dutilisation. e e ` 1.3.1 Simuler la situation
mo npn erc m ta t i x dn naone<oS edtdr><rtcr e sP liam >elseeumelli ><eje>cuse dsbdrneou Si noasdmoe<oal othe uliercdiuiar atr ls n teulc im sc r i>>n ny >l< n rc i< ln esr ><mue<ttiu ><u>cnpe><ueli di<Ae<tamdlnsS S moaoedlutedili el npebr><ro>< E e>std>cem< e mnete<cru rcdst nden r taxeMuiu>lc v tntlsje pe ie lu
F IG . 2 Diagramme de cas dutilisation appliqu a la simulation e`
(Voir Fig. 3)
usae ema mnts utnts eouc roae ama coilc rCiln urun oo r d r n t iL P iL mtcts nrnie eouc m ln par tama io iL
3
1.3.2
(Voir Fig. 4(a) et 4(b)) Dans le cadre de la situation initiale, nous ne savons pas quand le producteur va mettre un objet et quand le consommateur va prendre un objet dans le compartiment. Ceci sera mat rialis par un temps e e dattente al atoire. Ensuite, le producteur et le consommateur vont tenter deffectuer leurs actions e ` respectives. Si celles-ci echouent, alors ils se remettent a attendre un temps al atoire avant de refaire e une tentative.
1.3.3
(Voir Fig. 5(a) et 5(b) page suivante) e Pour chaque cas dutilisation el mentaire, lid e est de bloquer le compartiment si celui-ci nest e pas d j` bloqu , v rier l tat de ce dernier (vide ou plein), puis effectuer lop ration associ a la ea e e e e e` ` prise de lobjet (retourner lobjet) ou a la mise de lobjet (Accepter lobjet) du point de vue du compartiment. Le cas dutilisation nest pas repr sent , puisquil est en r alit compos des op rations de e e e e e e blocage et de d blocage du compartiment. e Remarque : Lorsquil y a une d pendance entre deux cas dutilisation, ceci se traduit par la e pr sence dune activit nomm e comme lun des cas dutilisation dans le diagramme dactivit s de e e e e lautre cas dutilisation. Cf le diagramme dactivit s de la simulation du producteur (Fig. 4(a)) qui e contient une activit Mettre objet dans compartiment. Dans le m me ordre did e, il serait possible de e e e ` substituer a cette activit le diagramme qui d crit le cas dutilisation du m me nom et de linclure dans e e e ` le diagramme de la simulation du producteur. Toutefois, ceci est a eviter puisque cela surchargerait le diagramme en question.
s a s p se sb ao s0 p ] st1 so ] pj[ s st1[ urj ]e 0 ib esrio[0sej[ oso[0sej[ oe <pt ]ee <pt sp s bjsbj1ao hp1ao d][t ]s cd ]s ]tp sb ss sb m de ed[d np e e' m uo a ta eaadttr mtonnttt oered npldbje acnn eanort rrsuA orcer er aate titor aue ubjn eieruA ioeP med lne tsM dte rtie
(a) Simuler le producteur (b) Simuler le consommateur
F IG . 5 Diagrammes dactivit s associ s aux cas dutilisations mettre et prendre un objet dans le e e compartiment
vmie ]nptpe eeto[tor minacD minacD pmior nptro rero re b c b c ditamql eltamql ]mpu imtu b neto[ neejut eeep mio[R ditact eltaee mbe ppn ]mjrA rtc ro ]ntoo vpec imrr nto[c it ete ete mq mq ro ro tpu tpu omiorl omiorl nacB nacB upt[to upt[to qedac qedac mnr minr oqilei oqlei m m r r ]utop ]utop b]m b]m ltbc ltbc nam[ nam[
(a) Mettre un objet (b) Prendre un objet
Une fois les diagrammes dactivit s r alis s, chaque cheminement possible dans un diagramme e e e dactivit se traduit sous la forme dun sc nario de cas dutilisation. Dans le cadre dune applicae e tion complexe, etudier de mani` res exhaustive tous les cheminements est impensable. Lid e est de e e s lectionner les cheminements qui vont mettre en evidence les interactions entre les diff rents objets e e ` du syst` me en vue de d terminer les interfaces des classes a laide des diagrammes de collaboration. e e
2
2.1
Diagrammes de collaboration
Lancement de la simulation
La simulation doit dabord cr er les entit s Producer (Producteur), Consumer (Consommateur) e e et CubbyHole (Compartiment). De toute evidence, le producteur et le consommateur doivent avoir connaissance du compartiment par lequel ils doivent communiquer. Cest pourquoi, le compartiment cr e est pass en param` tre aux op rations charg es de cr er le Producteur et le Consommateur. Enn, e e e e e e la simulation doit d marrer les fonctions principales (start) des deux threads Producer et Consumer. e Cest ce que nous pouvons voir sur le diagramme dactivit correspondant (Fig. 6). e
2.1.1
Comme evoqu en cours, il est facile de passer du diagramme de collaboration au diagramme de e s quences (Fig. 7 page suivante). Ce dernier a lavantage de montrer laspect temporel des echanges e de messages. A titre dexemple, nous montrons ici le diagramme de s quence r sultant pour la sie e mulation. Ce dernier met en evidence la cr ation des objets de type compartiment, producteur et e ` consommateur par rapport a la simulation.
2.2
Avant de tracer le diagramme de collaboration portant sur la mise dun objet dans le compartiment, nous allons nous int resser diagramme dactivit s Mettre un objet (Fig. 5(a) page pr c dente). Lid e e e e e e est de trouver un ou plusieurs cheminements dans ce diagramme nous permettant de passer par toutes les activit s de ce diagramme. Ici, le cas etant simple, il existe un cheminement permettant de couvrir e ` lint gralit des activit s : celui qui est a la verticale du point dentr e au point de sortie. e e e e ` Il reste donc a traduire ces op rations en messages entre les entit s intervenant dans le diagramme e e dactivit s : le producteur et le compartiment. Les messages sont : e la mise (put) dans le compartiment, le blocage ou v rouillage (lock) du compartiment, e le d blocage ou d verrouillage (unlock), e e lacceptation ou stockage (store) effectif de lobjet.
Cette traduction aboutit au diagramme de collaboration Mise dun objet dans le compartiment (Fig. 8(a)). La m me logique de construction sapplique au diagramme de collaboration concernant la prise e (get) dun objet dans le compartiment (Fig. 8(b)).
F IG . 8 Diagrammes de collaboration d crivant la mise et la prise dun objet dans le compartiment e Remarque : An de ne pas surcharger les diagrammes de collaboration, lorsquun appel sans type de retour (void) est r alis , le diagramme ne comporte pas de message de retour associ a ces appels. e e e` e Lorsque les diagrammes de collaborations ont et trac s, il est possible de d terminer les interfaces e e entre les divers objets. Les interfaces sont en r alit les messages echang s. Dans le cadre de cet e e e exemple, les messages sont en r alit les op rations contenues par nos classes. Il est d` s lors, possible e e e e de cr er le diagramme des classes de notre application. e
5 a s r t )t (: 4 a s r t )t (: u :C(r r oe s)ua nb e ol b Cy : c u m : mHbt: e r s n o C e e c3 l b u ue e ereryc2 c :cHbt: r r o :c o o)u e d d:C(r P Pb a u u 1u m :b e b s n uCb a:C ne HbtH : oli e cr y moy ee ar o : cb t: C l i l S ) (o
F IG . 7 Diagramme de s quences associ a la simulation e e`
(a) Mise dun objet dans le compartiment (b) Prise dun objet dans le compartiment
Le diagramme des classes fait egalement intervenir la classe Thread car il est pr cis dans l nonc e e e e que le producteur et le consommateur sont simul s par des threads. Nous pouvons remarquer la relae tion de g n ralisation qui relie les trois classes dans le diagramme des classes (Fig. 9). e e Il faut sp cier que la classe Simulation est le point dentr e du programme (main) et quelle e e contient, pour les besoins de la simulation, un producteur, un consommateur et un compartiment. De m me, le producteur et le consommateur contiennent une r f rence au compartiment quils e ee vont utiliser pour se passer les objets.
Une fois le diagramme des classes trac , nous pouvons compl ter ce dernier avec des diagrammes e e ` dactivit et des diagrammes de s quence d crivant les diverses op rations a effectuer. e e e e Toutefois, compte tenu de la complexit faible de lexemple pr sent , les diverses op rations efe e e e fectu es (le point dentr e, la mise et la prise dobjets) sont d j` document s en d tails. e e ea e e En revanche, il convient de faire quelques remarques sur la programmation des classes r sultantes e ` en Java par rapport a ce qui est expos dans les diagrammes UML ici pr sents. e e
3.1
3.1.1
En UML, le constructeur dune classe est une op ration comme une autre. Ainsi, les op rations e e create evoqu es pour les classes Consumer, Producer et CubbyHole sont en r alit des constructeurs e e e des classes concern es et pourraient etre nomm s en tant que tel. e e 3.1.2 Le verrouillage et d verrouillage du compartiment e
Si lon regarde les diagrammes de collaboration concernant la mise et la prise dun objet dans le compartiment (Fig. 8(a) et 8(b) page pr c dente), ainsi que les diagrammes dactivit re tant les e e e e m mes processus (Fig. 5(a) et 5(b) page 5), nous remarquons que la premi` re activit travers e est e e e e le verrouillage et la derni` re le d verrouillage du compartiment quelque soit le parcours choisi dans e e les diagrammes en question. Ceci est g r sp ciquement en Java par le mot cl synchronized. En ee e e somme, il est possible de simplier les diagrammes de collaborations associ s. Ceci est ainsi r alis e e e
meue e ta O+ c o n # eCk) o r bcc Olob:+ )tb(:)e # ycC)ebj)g ebeoooet# ournbjyO# H+uc:bb(u lb sHtctE be kr )( ot n )o # + occcleb oejle(jctiy+ t(u b:opslb lO::(u u ymH obytsoc +:tk(tl ucepl c)o :l)btjbj nc ( iue ueb Hbjnt mH + ubuc eoo m rbO:o rn:b bCe s u ye C)y elun n s y (s ongn o r eC::aru+erisy ureroc)+ olloclu HuS+ dd:ruy Heeteoer][su c+cHbat bb ebm b c Cc lbeb P ctro o C)+ ydo b Ps uba ctgHc P)b e mHtcrsnC:::biepueC:ar euo(t nHan rorebett rber murl(c oy (( ny eCra Cs s b ooe y + mu llu otm ia aur uor:b sd nuelu r:o =doc )+p HH (rc llc b T e a e r dtlti h
F IG . 9 Diagramme des classes 8
F IG . 10 Diagramme de collaboration simpli pour la prise dobjets e pour la prise dobjet (Fig. 10). ` La discussion concernant les sp cicit s de Java par rapport a UML etant termin es. Nous poue e e vons supposer que le code est pr t a etre g n r . Ce code sera entrepos sous forme de chiers qui e ` e ee e seront ensuite compil s pour ex cuter la simulation. Nous allons voir quels sont les composants que e e ceci g n` re pour la simulation. e e
Le diagramme de composants
` Chaque classe d velopp e est ecrite en java. Ceci r sulte en un chier a lextension .java. Ces e e e ` chiers sont ensuite compil s pour fournir les chiers a lextension .class contenant le bytecode e ` n cessaire a lex cution. Ensuite, pour lex cution, il faut lancer Simulation.class en utilisant la mae e e chine virtuelle Java. Lensemble des composants mis en jeu ainsi que leurs d pendances sont pr sentes e e dans le diagramme de composants (Fig. 11).
Le diagramme de d ploiement e
Le diagramme de d ploiement (Fig. 12 page suivante) est ici tr` s simple puisquil sagit dex cuter e e e la simulation sur une seule machine capable de supporter le poids dune machine virtuelle java. La version 1.5.0 du java development kit n cessite au minimum 64 Mo de m moire vive pour fonctionner. e e Ici les d veloppements et lex cution sont suppos s se d rouler sur un syst` me de type Linux. e e e e e
.S voi oilicaai oix v u am ntosm nt a aa msul u a n p nt e o o js t rl a cu c J u et ai e ci l.S u ete uae nt lx nle oix nc oixc c oie cu e bx et e ue tbx c e e e se eC u slte a le ac u u m b .P cx rC o eu b a bn nu ntsH ntse oill.s oixstl.le oixilld m u lc uscr ae cae cec po eey eare c citu cx c a c to ebx ebo it . vo au nu u e e au ncu atjP m oio vo a.s vo oc e m m r alr ao n pC u o o p r d jis H c jb o l r r a.s as eC y c eb er
F IG . 11 Diagramme de composants 9
F IG . 12 Diagramme de d ploiement e
Conclusion
Cet exemple met en oeuvre les principaux diagrammes employ s dans le cadre de la notation e UML : diagramme de cas dutilisation, diagramme dactivit s, e diagramme de collaborations, diagramme de s quences, e diagramme de classes, diagramme de composants, diagramme de d ploiement. e ` Comme nous pouvons le voir, il nest pas n cessaire, a chaque fois, dutiliser lensemble des e diagrammes disponibles pour effectuer lanalyse compl` te dun syst` me. Les autres diagrammes sere e viront eventuellement pour dautres types de programmes ou de syst` mes dinformation. e ` Lobjectif consiste simplement a etablir le support documentaire n cessaire pour comprendre le e syst` me d crit sous ses divers aspects. e e
Diagrammes dessin s avec Umbrello et retouch s a laide dInkscape, document g n r a laide de pdatex. e e ` e ee`
10