A classification of invasive patterns in AOP

apport   de recherche ISSN 0249-6399 ISRN INRIA/RR--6501--FR+ENG Thème COM INSTITUT N A TION AL DE RECHERCHE EN INFORMA TIQUE ET EN A UTOMA TIQUE A classification of in vasiv e patterns in A OP Freddy Munoz — Benoit Baudry — Olivier Barais N° 6501 March 2008 Centre de recherche INRIA Rennes – Bretagne Atlantique IRISA, Campus universitaire de Beaulieu, 3504 2 Rennes Cedex (France) Téléphone : +33 2 99 84 71 00 — Télé copie : +33 2 99 84 71 71 A classification of in v asiv e patterns in A OP F reddy Munoz, Benoit Baudry , O livier Barais Th` eme COM — Syst` emes communican ts ´ Equip es-Pr o jets T riskell Rapp ort de recherche n ° 6501 — March 2008 — 12 pages Abstract: Aspect-Oriented Progr amming (A OP) impr ov es modula rity b y encapsulating cr osscutting concer ns in to aspects. Some m echanisms to comp os e asp ects a llow in v asiveness as a mean to in tegra te concerns. In v asiveness means that A OP languag es hav e unrestr icted acc e ss to prog ram prop erties. Suc h kind of languag es are interesting beca use they allow p erforming co mplex o pe r ations and b etter intro duce functionalities. In this rep ort we pr esent a classifica tion o f inv asive patterns in AOP . This cla ssification character izes the aspects in v asive behavior a nd allows develop ers to abstract ab out the asp ect incidence ov er the progra m they cro s scut. Key-w ords: Aspe c t- oriented pro gramming, Classification system, Inv asive A OP . R´ esum´ e : Pas de r´ es um´ e Mots-cl´ es : Pas de motclef A classific ation of invasive p atterns in AOP 3 1 Int ro duction Aspe c t- oriented Pro gramming (A OP ) is a par adigm that enhances curren t ap- proaches to mo dularizing so ft ware. A OP enable s s e paration of concer ns that crosscut the implemen tation of a system. This is done by encapsula ting cross- cutting concerns into sing le units called asp e cts . An asp ect itself is comp osed of several units that rea lize the crosscutting behavior. Aspe c ts als o pr ovide po intin g elements that designate w ell defined p oints in the program executio n or structure. These ar e the p o int s wher e the program executes t he cr osscut- ting b ehavior. Different appr oaches to AOP have b een prop ose d [5, 6, 10, 9, 7, 1]. Each of these appr oaches provide a differ e nt mechanism to compo se a sp ects with the base program. These c omp osition mechanisms range fr om simple pro gram augmentation to mor e complex op erations such as b ehavior replac e ment . Invasive co mpo sition mechanism a llow dev elop ers to manipulate a lmo st a ny structure and behavior of the ba se prog ram. Invasive AOP approa ches r ealize inv asive comp o sition mechanism. Invasiveness is the a bility of inv asive A OP to manipulate the progr am structur e s and b ehavior. Inv asive AOP pro vides several stra teg ies to manipulate the base progr am. These str ategies range from less inv asive suc h as the augmentation of a pro c edure execution to mo re inv asive ones such as the r eplacement o f a pro cedur e execution. This rep or t prese nts a clas sification sys tem for inv asive A OP . This cla ssifica- tion system fo cuses on the inv asive b ehavior o f asp ects ov er the bas e progra m. W e construct this class ification sy s tem by studying the inv asive structures of Aspe c tJ [3], ho wev er, we think that it can b e adapted to other inv asive lan- guages. The reminder of this rep or t is organized as follows. In sectio n 2 w e study the Asp ectJ structure s in order to der ive our classific a tion of inv asive A OP . In section 3 we intro duce o ur classification of inv asive asp ects. In section 4 we discuss r elated work. Finally sec tio n 5 concludes. 2 Classifying Inv asiv e AOP Each pr ogramming par adigm pr o motes its own way to encapsula te concerns . F o r ex ample, the ob ject-or ient ed par adigm encapsula tes co ncerns in c lasses, fields and metho ds. It also defines a protec tio n level for each o ne of them. This ensures that pro p erties will b e accessed according to their p er mission. Inv asiveness breaks the encapsulation that each par adigm promotes and pro- vides a mean to access protected pr o p erties. F o r example, asp ects can access classes, metho ds and fields wha tever their p ermissio n. Developers can fruitfully use inv asiveness. F or example, they can use it to check the preser v atio n o f sys- tem prop erties [11]. How ever, dev elop ers can use in v a siveness to inv alidate some desirable system pro p e r ties, inten tionally or uninten tionally . The duality in the usage of inv asiveness mo tiv ates us to prop ose a classifica- tion system for inv asive AOP . Our c lassification system provides the following bene fits.  It enables the characterizatio n of as pe c ts with precise inv asive b ehavior (in v a sive pattern). RR n ° 6501 4 Munoz & Ba udry & Bar ais  It enables developer s to reason ab out asp ects and discr iminate when they could repr esent a risk to the base progr am. W e build the cla ssification sys tem by studying the in v a sive structur es av ail- able in AspectJ. Once iden tified the different poss ibilities it provides, w e pro ceed to derive our classifica tion system. 2.1 Running example T o illustrate our characterizatio n appr oach, in listing 1 we present the skeleton implemen tation of an ordere d list class ( My Array List ). All the attributes in this list ar e priv ate to the cla s s. E le ments added using the add metho d (line 8) are sto res in the elem ents array (lin e 2 ). E lements a re retrieved b y using the get metho d (line 1 1). The sp ecific position of an element in the el ement s array is obtained by using the ind exOf method (line 12). An element is removed from the list by using the remov e metho d (lines 13 -14), this metho d removes an element by using its p os itio n or the original e le ment . The fir s t and last element in the lis t are retrieved by us ing the metho ds firs t a nd las t (lines 15,1 6). All the elements in the list ca n b e removed by using the clea r metho d (line 9 ). 1 public class MyArr ayList { 2 priv ate Ob ject[] elements; 3 priv ate in t initialSize=0; 4 priv ate in t growF ac tor =5; 5 priv ate in t size=0; 6 public MyArr ayList( in t grow, in t initialSizei) { ... } 7 public MyAr rayList () { .. } 8 public b o olean add(O b ject o) { ... } 9 public void clear() { ... } 10 public b o o l ean contains(Ob ject o ) { ... } 11 public Ob ject get ( int index) { ... } 12 public in t indexOf(Ob ject o) { ... } 13 public b o o l ean remov e(Ob ject o) { ... } 14 public Ob ject remove ( in t index) { ... } 15 public Ob ject first() { ... } 16 public Ob ject last() { ... } 17 public in t size() { ... } 18 } Listing 1: Skeleton implementation of an ordered list example Listing 2 pr esents the co de of our example a s p e ct. This asp ect ( My Aspec t ) realizes a set of advices an Inter-type declar ations that affect in different wa ys the My ArrayL ist class. The declar ation in line 3 intro duces the parent in terface Compar able into the MyArr ayList class hier a rch y . The int er- type in line 5 adds the metho d compar eTo to the MyArr ayLis t class. Analogo us ly , the inter-type of line 7 adds the field maxSi ze . The advice in lines 9 -12 execute a lo gging facility just b e fore the ex ecution of the add metho d. The advice in lines 14 -19 print a message in to the standard output b efore and after the execution of the add metho d. The advice in lines 21-2 4 replaces the execution of the fi rst metho d and ex ecutes the last metho d instead. The advice in lines 26-32 ex e c utes the add metho d only when no n null v alue s ar e passed as par ameters. The advice in INRIA A classific ation of invasive p atterns in AOP 5 lines 34-42 adds e a ch element of a collec tion in to the list. The advice in lines 44-48 replaces the parameter ob ject (ob ject to b e inserted) b y an string, then the string is inserted instead of the ob ject. The advice in lines 4 8-52 r eads the field curr ent size and print it to the standar d output. Finally , the adv ice in lines 54-57 decrea ses the v alue of cur rentS ize by 1 . 1 public privilege d asp ect MyAsp ect { 2 3 declar e parents: MyArrayList implem e n ts Compara ble; 4 5 publi c b o o lean MyArrayList.compareT o(Ob ject o) { ... } 6 7 public int My ArrayList .maxSize=10 0; 8 9 b e fo re (MyAr rayList lis t,O b ject o): 10 execution ( * MyArrayList+.add(Ob ject+)) && args ( o) & & this (lis t) { 11 logger.debug(”Adding ob ject ”+o.toStr ing()); 12 } 13 14 v oid around ((MyArrayList list,Ob ject o): execution ( * MyArrayList+.add(Ob ject)) && 15 args (ob j) && target (list) { 16 System.out.println(”adding ob ject:”+ob j); 17 pro ceed (ob j,list); 18 System.out.println(”ob ject added ” ); 19 } 20 21 b o olean around (MyArrayList list): 22 execution ( * MyArrayList+.first()) && thi s (list) { 23 return list.la s t(); 24 } 25 26 b o olean around (MyArrayList list,Ob ject o): 27 execution ( * MyArrayList+.add(Ob ject+)) && args ( o) & & this (lis t) { 28 if (o!= n ull ) { 29 return pro ceed (list,o); 30 } 31 return false ; 32 } 33 34 b o olean around (MyArrayList list,Collection c): 35 call ( * MyArrayList+.add(Collection+)) && args (c) && this (list) { 36 for (Ob ject o:c) { 37 pro ceed (list,o); 38 } 39 return true ; 40 } 41 42 b o olean around (MyList list,Ob ject o): 43 call ( * MyArrayList+.add(Ob ject+)) && args (o) & & this (lis t) { 44 o = new String(”ob ject”+ o.toString()); RR n ° 6501 6 Munoz & Ba udry & Bar ais 45 return pro ceed (list,o); 46 } 47 48 after (MyArrayList list): 49 execution ( * MyArrayList+.add(..)) && thi s (list) { 50 in t size=list.currentSize; 51 logger.debug(”curre nt size: ”+size); 52 } 53 54 b efore (MyArr ayList list): 55 execution ( * MyArrayList+.add(..)) && thi s (list) { 56 list.currentSize=list.current Size − 1; 57 } 58 59 b o olean around (MyArrayList list, in t i): 60 call ( * MyArrayList+.get( in t )) & & args (i) && this (list) { 61 Ob ject o= pro ceed (lis t,i); 62 return o.to String(); 63 } 64 } Listing 2: MyAsp e ct ex ample 2.2 In v asiv e AOP: The case of Asp ec t J Aspe c tJ [3] is the mos t prominent realiz ation of inv asive a sp ects. It rea lizes the crosscutting behavior on advic es and designa ting the places where this b ehavior m ust b e wo ven w ith p o intcut expres sions. Poin tcuts are r egular expr essions that match well defined p oint in the structure (static) and exec ution (dynamic) of the pro gram. In Asp ectJ, asp ects a re comp osed o f advic e s, p ointcuts, inter-type decla- rations and inter-type pa rent declar ations. Advices a r e use d to mo dify the progra m flow and write or rea d fields. An a dvice ca n b e declared inside a privi- leged asp ect, which means that it is enabled to igno re the ob ject-oriented access po licy . Inter-type declara tions are used to intro duce metho ds and fields into a target class. Inter-t yp e parent declara tio ns are declarations o f inher itance that mo dify the clas s hierar ch y . Aspe c tJ a llows develop ers to implemen t v arious behaviors on advices. W e summarize them by using the a ctions advices may per form in the following list.  The advice do es not mo dify the b ehavior of the metho ds it cr osscuts. (Listing 2, lines 9-12, 1 4-19)  The advice replace s the behavior of the methods it cross cuts, the original metho ds are never inv oked. (Listing 2, lines 21-24 )  The advice conditionally replaces the behavior of the metho ds it crosscuts. (Listing 2, lines 26-32 )  The advice repla ces the b ehavior of the methods it crosscuts. It in vok es t wo or mor e time the o riginal metho d. (Listing 2 , lines 34 - 40) INRIA A classific ation of invasive p atterns in AOP 7  The advice invok es a metho d declared outside its declaring as p ect. (List- ing 2, line 11)  The advice changes the argument v alues of the metho ds it cr osscuts. (List- ing 2, lines 42-46 )  The a dv ice replace s the res ult of the metho d execution. (Listing 2, lines 59-63  The advice reads or writes ob ject fields v alues. (Listing 2, lines 50, 56) Aspe c tJ allows develop e rs to mo dify the progra m struc tur e. W e summar ize the mo difications develop ers can implement on asp ects in the following list. It is worth to remar k that thes e mo difications are per formed a t the asp ect level.  The a s pe ct inser ts new fields into a tar get clas s by using an inter-t yp e declaration. (Listing 2, line 7)  The asp ect inse r ts new metho ds into a target class by using an inter-t yp e declaration. (Listing 2, line 5)  The asp ect mo difies the class hier arch y by us ing an inter-t yp e pare nt dec- laration. (Listing 2, line 3) These list of in terven tions r a nge from simple a ugmentation to more inv asive ones lik e complete replacing the target metho d or write a protected field. W e motiv ate our c lassification on these factual interv ention w e pr o ceed to identify different in v asive b ehavior that w e call invasiveness p atterns . 3 Classification System W e can identify three axes for our clas s ification. The first corresp onds to ho w developers can use adv ic es to affect the pro gram control flow. The seco nd corres p o nds to how developers can us e advic e s to a ffect the data flow, changing fields, metho ds par ameters and returning v alues. The third co rresp onds to how developers ca n use asp ects to mo dify the pro g ram structure. 3.0.1 Con trol Flo w Classifies a dvices according to the b ehavioral interaction b etw een them and the metho ds it cro sscuts. Augmentation : After cr osscutting, the b o dy o f the metho d is always executed. The a dvice augments the b ehavior of the metho d it crosscuts with new behavior that do es not int erfere with the o riginal be havior. The a dvices in Listing 2 , lines 9-12, 14- 19 rea lize the inv asiveness pattern Augmentation . R eplac ement : After crosscutting, the bo dy of the metho d is never executed. The a dvice completely replaces the b ehavior o f the metho d it cross cuts with new b ehavior. This k ind of advices e limina te a part of the base co de. The advice in Listing 2, lines 21-2 4 rea lizes the inv asiveness pattern R eplac ement . The advice in lines 59-63 is an sp ecial case of Rep lac ement , this b e cause it executes the or iginal b ehavior to la ter replac e the obta ined result. RR n ° 6501 8 Munoz & Ba udry & Bar ais Conditional r eplac ement : After crosscutting, the bo dy of the metho d is not alwa ys e x ecuted. The advice conditionally inv okes the bo dy of the method and p otentially r e places its b ehavior with new b ehavior. Examples of this kind of advices ar e advices realizing transactio n, acce ss co ntrol, etc. List- ing 2, lines 26-32 realizes the in v asiveness pattern Co nditional re plac ement . Multiple : After crosscutting, the b o dy of the metho d is executed more than once. The a dvice inv okes tw o or mor e time the b o dy o f the metho d it crosscuts genera ting p otentially ne w b ehavior. The advice in Lis ting 2 , lines 34 -40 rea lizes the inv asiveness pattern Multiple . Cr ossing : After crossc utting, the advice inv o kes the b o dy o f a metho d (or several methods) that it do es not crosscut. The advic e hav e a dep endency to the class owning the inv oked method(s). The advice in Lis ting 2, lines 9-12 r ealizes the inv asiveness patter n Cr ossing . 3.0.2 Data Access Classifies advic es accor ding to the access they perform to ob ject fields and metho d a rguments. Write : After cros scutting, the advice writes an ob ject field. This ac cess breaks the protection declared for the field and can modify the behavior of the underlying computation. The advice in Listing 2, lines 5 4-57 realizes the inv asiveness pattern Write . R e ad : After cro sscutting, the advice reads an ob ject field. This access break s the protection declared for the field and can potentially expose sensitive data. The advice in Listing 2, lines 4 8-52 realizes the inv asiveness pattern R e ad . Ar gument p assing : After cros scutting, the advice modifies the arguments o f the metho d it cr o sscuts and then in vokes the b o dy of the metho d. The bo dy of the metho d alwa ys executes at least once. T he adv ic e in Listing 2, lines 42 -46 rea lizes the inv asiveness pattern Ar gument p assing . 3.0.3 Structural Classifies asp ects acc o rding to the mo dificatio n performed they p erform to the existing structure of a class. Hier ar chy : The asp ect mo difies the declared class hierar chy . F or e xample, the asp ect a dds a new parent interface to an existing one. An exa mple of this is the declara tion in Lis ting 2, line 3. Field addition : The asp ect adds new fields to an existing class declar ation. These fie lds dep ending o n their protection can b e acceded by refere nc- ing an ob ject instance o f the affected class. An example of this is the declaration in Listing 2, line 7. Op er ation addition : The aspect a dds new metho ds to an ex iting class decla - ration. These metho ds dep ending on their protection can be acceded b y referencing an ob ject insta nce of the affected clas s. An example of this is the decla ration in Listing 2, line 5. INRIA A classific ation of invasive p atterns in AOP 9 The groups w e have presented describe the as pe c t inv asive b ehavior in differ- ent dimensions, a nd most of them are co mplemen tary . F or exa mple, a n advice cannot p er form data access without executing and therefore a W rite advic e can also rea liz e and Augmentation advice. Ho wev er, some classifica tion cate- gories are incompatible, A ugmentation , Rep lac ement and Conditional R eplac e- ment canno t co-ex is t in the same advice. Note that this clas sification is still inco mplete. It do es no t addre ss case s like the exc e ptions raised by advices. How ever, it allows us to characterize the behaviora l interaction b etw een advices and metho ds, ma jor structur e mo difica- tions and data access. 4 Related w ork In [8] categor ies of direct and indirect interactions b etw een asp ects and meth- o ds ar e iden tified. Direct interaction is whether an a dv ice in terferes with the execution of a method, whe r eas indirect is whether a dvices and methods may read/wr ite the same fields . This cla ssification is similar to o urs, how ever, it addresses a different dimension. W e identify inv asiveness patterns instead o f direct/indirect in terac tions. Katz [4] reco gnizes the fact that a sp ects can b e har mful to the base co de and the need of spe c ific a tion o n asp ect-o riented applications. Our approach a grees with his ideas and likewise we pr op ose a mean to write such sp ecificatio ns. F ur thermore, he describ es three g roups o f advice s a ccording to their prop er- ties. Sp e ctative aspects, which do not influence the underlying computation, R e gulatory asp ects, which change the c o ntrol flow but do not a ffect existing fields, a nd Invasive asp ects, which affect existing fields. This classifica tion is similar to our s, how ever, our characterizatio n o f is more fine grained. The tw o first cor resp ond to o ur behaviora l class ific a tion and the last to our data access classification. Clifton and Leav ens pro p ose Sp e ctators and Assistants [2]. Spectators are advices that do not affect the control flo w of the a dv ised metho d and do not affect existing fields. Assista nt s can change the control flow of the advised metho d and a ffect ex isting fie lds . Sp e ctator are similar to our class ification category A ugmentation and R e ad in the sense that they do not in terfere with the mainline computation or write fields. All other class ification ca tegories a re equiv alent to Assistants . Nevertheless, we hav e achiev ed a mo re fine gr anularit y level in our classifica tion. 5 Conclus ions and F uture w ork In this rep ort w e have pre s ented a characterization of in v asive b e havior. Such a characteriza tion is enco ded as a classific a tion of inv asive a sp ect oriented pro- graming. The comp onent of this cla s sification represent inv asiveness patter ns , i.e. the wa ys in which AOP can b e inv asive. The characterization of inv asive aspects allow dev elop ers to rec o gnize a nd reason about the potential risks introduced b y asp ects in to the bas e progra m. W e think that this is the fir st step to a bigger sp ecification framework that will RR n ° 6501 10 Munoz & Ba udry & Bar ais make develop e r s more co nfident in AOP . In future work we will explor e the creation of an asp ects - bas e prog ram sp ecificatio n framework. References [1] Christoph Bockisch, Matthew Arnold, T om Dink elaker, and Mira Mezini. Adapting virtual machine techn iques for seamless asp ect s uppo rt. In ACM, editor, ACM Sigplan International Confer en c e on Obje ct-oriente d Pr o gr am- ming, Systems, L anguages, and A pplic ations (OOPSLA) 2006 , 20 06. [2] Curtis Clifton and Gary T. Leav ens. O bservers a nd assistants: A prop osal for mo dular aspect-or iented reasoning . In Ron Cytr on and Gar y T. Leav ens, editors, FO AL 2002: F oundations of Asp e ct-Orient e d L anguages (AOSD- 2002) , pag es 33 –44, March 2002 . [3] htt p://ww w .a sp ectj.org. Aspe c tj. [4] Shmuel Katz. Diag nosis of harmful asp ec ts using regr ession verification. In Curtis Clifton, Ralf L¨ ammel, and Gary T. Leavens, editor s, F OAL: F oundations Of Asp e ct -Oriente d L angu ages , pages 1–6 , Ma rch 200 4. [5] Gregor Kiczales. Aspec t or iented pro gramming. ACM SIGPLAN Notic es , 32(10):16 2–16 2, Octob er 1997. No pa p er in v olume, but table of co nten ts includes an entry for this invited talk . [6] Mira Me z ini and Kla us Oster mann. Conquering asp ects with caesar . In AOSD ’03: Pr o c e e dings o f the 2nd international c onfer enc e on Asp e ct- oriente d softwar e development , pag e s 9 0–99 , New Y ork, NY, USA, 200 3. A CM. [7] Renaud Pawlak. Spo on: anno tation-driven progra m tra nsformation — the aop case. In AOMD ’05: Pr o c e e dings of the 1st workshop on Asp e ct oriente d midd lewar e development , New Y or k, NY, USA, 2005 . ACM. [8] Martin Rinard, Alexandru Salcia nu, and Suhab e Bugr a ra. A classifica- tion system and analysis for in teractio ns in asp ect-or iented progr ams. In F oundations of Softwar e Engine ering (FSE) , pages 147–158 . ACM, Octob er 2004. [9] Davy Suv´ ee, Bruno De F raine, and Wim V ander p erren. A symmetric and unified a pproach tow ards combining asp ect-o riented and comp onent-based softw are development. In Ian Gorton, Geor ge T. Heineman, Ivica Crnko vic, Heinz W. Schmidt, Judith A. Stafford, Clemens A. Szyp erski, and K urt C. W a llnau, editors , CBSE , volume 4063 of L e ctur e Notes in Computer S ci- enc e , page s 114–1 22. Spring e r , 20 06. [10] Davy Suv´ ee, Wim V anderp err en, a nd Viviane Jonckers. Jasc o : a n a sp ect- oriented appro ach tailo red for comp onent based soft ware developmen t. In AOSD ’03: Pr o c e e dings o f the 2nd international c onfer enc e on Asp e ct- oriente d softwar e development , pag e s 2 1–29 , New Y ork, NY, USA, 200 3. A CM. INRIA A classific ation of invasive p atterns in AOP 11 [11] Dean W ampler. Contract4J for design by contract in Jav a: Design pattern- like proto co ls and aspec t in terfaces. In Yv onne Coady , David H. Lo r enz, Olaf Spinczyk, a nd Eric W ohlstadter, editors, Pr o c e e dings of the Fifth AOSD Workshop on Asp e cts, Comp onents, a nd Patterns for In fr astru c- tur e Softwar e , pag es 27 –30, Bonn, Germa ny , Ma rch 20 20 06. P ublished as Univ ers ity of Vir ginia Co mputer Science T echnical Rep o rt CS–2 006–0 1 . RR n ° 6501 12 Munoz & Ba udry & Bar ais Con ten ts 1 In tro du ctio n 3 2 Classifying Inv asiv e A OP 3 2.1 Running e x ample . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Inv asive AOP: The c ase of Asp ectJ . . . . . . . . . . . . . . . . . 6 3 Classification System 7 3.0.1 Con trol Flow . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.0.2 Data Access . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.0.3 Structural . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4 Related w ork 9 5 Conclusions and F uture w ork 9 INRIA Centre de recherche INRIA Rennes – Bretagne Atlantique IRISA, Campus universitaire de Beaulieu - 35 042 Rennes Cedex (France ) Centre de recherc he INRIA Fut urs : Parc Orsay Uni versit é - ZA C des V ignes 4, rue Jacques Monod - 91893 ORSA Y Cedex Centre de recherc he INRIA Nan cy – Grand Est : LORIA, T echnopôle de Nancy-Bra bois - Campus scientifique 615, rue du Jardin Botani que - BP 101 - 54602 V illers-lès-Nanc y Ced ex Centre de recherc he INRIA Gren oble – Rhône-Alpes : 655, av enue de l’Europe - 38334 Montbonnot Saint-Ismier Centre de recherc he INRIA P aris – Rocquenc ourt : Domai ne de V oluceau - Rocquenc ourt - BP 105 - 78153 L e Che snay Cedex Centre de recherc he INRIA Sophia Antipolis – Méditerranée : 2004, route des Lucioles - BP 93 - 06902 Sophia Antipoli s Ce dex Éditeur INRIA - Domaine de V olucea u - Rocqu encourt, BP 105 - 78153 Le Chesnay Cedex (France ) http://www.inria.fr ISSN 0249 -6399