Universit de Montral e e

Infrence statique et par contraintes des relations de composition dans des e programmes Java

par Norddin Habti

Dpartement dinformatique et de recherche oprationnelle e e Facult des arts et des sciences e

Mmoire prsent ` la Facult des tudes suprieures e e ea e e e en vue de lobtention du grade de Ma `s sciences (M.Sc.) tre e en informatique

Janvier, 2009

c Norddin Habti, 2009.

Universit de Montral e e Facult des tudes suprieures e e e

Ce mmoire intitul : e e Infrence statique et par contraintes des relations de composition dans des e programmes Java

prsent par : e e Norddin Habti

a t valu par un jury compos des personnes suivantes : eee e e Julie Vachon prsident-rapporteur e Stefan Monnier directeur de recherche Yann-Gal Guhneuc e e e codirecteur Victor Ostromoukhov membre du jury

Mmoire accept le e e

 RESUME

La relation de composition est une relation entre deux classes qui ncessite quune inse tance dune classe (appele partie ou composant) soit incluse, au plus, dans une instance e dune autre classe (appele tout ou objet composite) ` un moment donn. Cette ncessit e a e e e impose des contraintes sur le lien qui unit le tout ` ses parties ; elles concernent principaa lement les proprits dexclusivit (non partageabilit) et de dpendance (simultanit) ee e e e e e de vie des parties par rapport au tout. Les langages de modlisation par objets permettent diverses smantiques de la relation e e toutpartie, cependant les principaux langages de programmation orients objets norent e pas une syntaxe pour reprsenter de faon prcise et explicite une relation entre un tout e c e et ses parties. De plus, il nexiste aucun outil ecace qui peut vrier et valider les e relations de composition dans un programme. La plupart des outils dingnierie inverse e chouent ` identier statiquement ces relations ; gnralement, ils se limitent ` utiliser e a e e a la dclaration dun champ pour infrer une relation toutpartie. Il y a donc une rupture e e entre la modlisation et limplmentation et, par consquent, il est dicile de vrier si e e e e les exigences dnies lors de la phase de spcication ont t respectes durant la phase e e ee e dimplmentation. e Dans ce mmoire, nous prsentons une nouvelle approche pour dnir la relation e e e de composition dans un langage de programmation orient objets ; nous dnissons des e e proprits qui nous permettent de formaliser la relation entre un tout et ses parties direcee tement dans le langage de programmation. Nous avons implment notre approche pour e e identier statiquement les relations de composition dans des programmes Java. Notre implmentation est base sur des contraintes que nous avons tablies pour contrler e e e o lutilisation des rfrences et ainsi pouvoir vrier la prsence des relations de composiee e e tion. Mots cls: Composition, ingnierie inverse, langages de modlisation, Java. e e e

ABSTRACT

Composition is a strong form of wholepart relationship between two classes that requires that an object of one class (known as component or part) be included in at most one instance of some other class (known as composite or whole) at a time. This restriction imposes constraints on the link between the whole and its parts; those constraints concern the exclusivity and lifetime dependency of the parts with respect to the whole. Modeling languages provide various semantics of the wholepart relationship; however there is no corresponding facility in standard programming language. Moreover, there is no eective tool that can identify and verify composition relationships among classes in a program consistently. Most reverse engineering tools fail to identify statically these relationships. Usually, they simply infer a wholepart relationship using instance elds. Therefore, there is a gap between design and code, and it is dicult to verify whether the requirements dened in the analysis and design phases have been respected during the implementation phase. In this thesis, we propose a formal denition of the composition relationship; we dene properties that allow us to formalize the relationship between a whole and its parts directly in the Java programming language. To validate our approach, we have implemented our denition and we identify statically composition relationships in Java programs using a constraint-based system. The constraints enable the program users to better understand the results and thus adjust the program or add annotations in the code to make explicit the composition relationships and their rationale. Keywords: Composition, reverse engineering, modeling languages, Java.

` TABLE DES MATIERES

RESUME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ` TABLE DES MATIERES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

iii iv v

DEDICACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii REMERCIEMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CHAPITRE 1 : INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Contexte : relation de composition, langages de programmation orients e objets, ingnierie inverse . . . . . . . . . . . . . . . . . . . . . . . . . . . . e 1.2 Objectif : proposer une dnition de la relation de composition qui soit e proche du code source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Contributions : une nouvelle approche pour dnir et identier statiquee ment les relations de composition dans des programmes Java . . . . . . . 1.4 Organisation du mmoire . . . . . . . . . . . . . . . . . . . . . . . . . . . e 2 3 4 4 4 5 6 7 8 9 2 1 ix 1

CHAPITRE 2 : ETAT DE LART . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Les relations entre les classes : association, agrgation et composition . . . e 2.1.1 2.1.2 2.2 2.3 2.4 2.5 Dnition de la relation de composition dans UML . . . . . . . . . e Exemple dimplmentation de la relation de composition en Java . e

Proprits de la relation toutpartie . . . . . . . . . . . . . . . . . . . . . ee Analyse de pointeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Infrence de lunicit des rfrences . . . . . . . . . . . . . . . . . . . . . . e e ee Identication de la relation de composition . . . . . . . . . . . . . . . . .

CHAPITRE 3 : NOTRE DEFINITION DE LA RELATION DE COMPOSITION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

vi 3.1 3.2 3.3 Dnitions : variable, rfrence et objet . . . . . . . . . . . . . . . . . . . e ee Notre dnition de la relation de composition . . . . . . . . . . . . . . . . e Exemples de relations de composition . . . . . . . . . . . . . . . . . . . . 3.3.1 3.3.2 3.3.3 3.3.4 3.4 Exemple 1 : porte dune rfrence . . . . . . . . . . . . . . . . . . e ee Exemple 2 : rfrence temporaire sur un objet . . . . . . . . . . . . ee Exemple 3 : rfrences non-temporaires sur un objet . . . . . . . . ee Exemple 4 : rfrences entre composants du mme objet composite ee e 12 13 14 14 15 16 16 17

Modlisation de la relation de composition . . . . . . . . . . . . . . . . . . e

CHAPITRE 4 : DEFINITION DES CONTRAINTES SUR LUTILISA TION DES REFERENCES . . . . . . . . . . . . . . . . . . 4.1 Analyse de la relation de composition . . . . . . . . . . . . . . . . . . . . 4.1.1 4.1.2 4.1.3 4.1.4 4.1.5 4.2 4.3 4.4 Reprsentation du code source Java . . . . . . . . . . . . . . . . . e Instructions daectation . . . . . . . . . . . . . . . . . . . . . . . Cration dobjet : T x = new T() . . . . . . . . . . . . . . . . . . . e Nullication : T x = NULL . . . . . . . . . . . . . . . . . . . . . . 19 20 20 23 24 24 25 26 29 30 32 32 33 33 34 34 34 34 34 35

Appel de mthode : invoke r.m(p0, p1, ...) . . . . . . . . . . . . . . e

Etat de la copie de la rfrence ` un point de programme . . . . . . . . . ee a Dnition des contraintes sur les variables logiques . . . . . . . . . . . . . e Formalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CHAPITRE 5 : IMPLEMENTATION . . . . . . . . . . . . . . . . . . . . . . 5.1 5.2 Prsentation de notre implmentation . . . . . . . . . . . . . . . . . . . . e e Cadriciel Soot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5 5.2.6 5.2.7 Instruction de copie . . . . . . . . . . . . . . . . . . . . . . . . . . Instruction didentit . . . . . . . . . . . . . . . . . . . . . . . . . . e Cration dobjet . . . . . . . . . . . . . . . . . . . . . . . . . . . . e Ecriture dans un champ . . . . . . . . . . . . . . . . . . . . . . . . Lecture dun champ . . . . . . . . . . . . . . . . . . . . . . . . . . Ecriture dans un champ statique . . . . . . . . . . . . . . . . . . . Lecture dun champ statique . . . . . . . . . . . . . . . . . . . . .

vii 5.2.8 5.2.9 Ecriture dans le tableau . . . . . . . . . . . . . . . . . . . . . . . . Lecture dun lment du tableau . . . . . . . . . . . . . . . . . . . ee 35 35 35 35 36 36 36 36 37 38 40 40 45 45 49 49 51 52

5.2.10 Instruction de coercition . . . . . . . . . . . . . . . . . . . . . . . . 5.2.11 Appel de mthode . . . . . . . . . . . . . . . . . . . . . . . . . . . e 5.2.12 Retour de mthode . . . . . . . . . . . . . . . . . . . . . . . . . . . e 5.2.13 Instruction Phi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Cadriciel Choco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 5.3.2 5.3.3 5.3.4 5.4 Probl`mes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e Variables et domaines . . . . . . . . . . . . . . . . . . . . . . . . . Contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rsolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e

Un exemple pour illustrer le fonctionnement de notre implmentation . . e

CHAPITRE 6 : VALIDATION ET LIMITATIONS . . . . . . . . . . . . . . 6.1 6.2 6.3 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Solutions conservatrices pour lanalyse des cas particuliers . . . . . . . . .

CHAPITRE 7 : CONCLUSION ET PERSPECTIVES . . . . . . . . . . . . BIBLIOGRAPHIE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

` A mes parents et ma femme.

REMERCIEMENTS

Jaimerais tout dabord remercier mes directeurs Stefan Monnier et Yann-Gal Guhneuc e e e pour leur soutien et aide prcieuse tout au long de cette maitrise ainsi que pour le temps e quils ont consacr ` la correction des versions prliminaires de ce mmoire. ea e e

Je tiens ` remercier galement tous les membres du laboratoire GEODES. a e

Je remercie aussi ma femme qui na jamais cess de mencourager et de mappuyer. e

Enn, je remercie les membres de mon jury, Julie Vachon et Victor Ostromoukhov pour avoir accept dvaluer ce travail et pour leurs commentaires constructifs. e e

CHAPITRE 1

INTRODUCTION

1.1

Contexte : relation de composition, langages de programmation orients e objets, ingnierie inverse e Les langages de programmation orients objets, tels que Java, orent des syntaxes e

et des smantiques pour reprsenter les dirents concepts du paradigme orient objet e e e e (classes, objets, encapsulation, hritage, polymorphisme). Cependant, ils norent pas e une syntaxe explicite pour reprsenter les relations entre les classes et, en particulier, e reprsenter les relations toutpartie ; typiquement, limplmentation de ces relations est e e faite en dclarant dans le tout un champ du type de la partie. Ainsi, il est impossible, e a ` partir de la dclaration dun champ, de savoir sil sagit dune relation dagrgation e e ou de composition. Cela cre des incompatibilits et des carts entre les programmes et e e e leurs mod`les (e.g., diagrammes de classes UML) construits avec des outils dingnierie e e inverse et, par ailleurs, cela cre une rupture entre la phase de modlisation et la phase e e dimplmentation [GAA04]. e Distinguer le type dune relation entre deux classes et en particulier identier statiquement les relations de composition constitue un d tr`s particulier pour les chercheurs ; e e la relation de composition dnit des proprits et des contraintes prcises, notamment e ee e lunicit dappartenance (non partageabilit) et la dpendance existentielle (simultanit e e e e e de vie et de mort) entre un tout et ses parties. Une mauvaise implmentation de la ree lation de composition peut aller ` lencontre des exigences dnies lors de la phase de a e spcication, par exemple sur le comportement fonctionnel qui a t dnie pour un proe ee e gramme lors de la phase de modlisation ou sur les aspects de scurit qui concerne les e e e droits dacc`s aux objets du programme (comme le bogue signers en Java 1.1 [Mil05]). e Le principal probl`me qui empche lidentication des relations de composition dans e e un programme rside dans labsence de concept et de constructions propres ` la dnition e a e et ` la dclaration de relations de composition dans les langages de programmation ; les a e

2 langages de programmation permettent la dclaration dun champ (simple, tableau, ou e collection) pour exprimer une relation toutpartie, mais norent aucune syntaxe pour spcier les contraintes ` imposer sur lutilisation de ce champ. Il revient aux programe a meurs de sassurer que les parties seront exclusives au tout et quelles seront dtruites e aussitt que le tout sera dtruit. o e 1.2 Objectif : proposer une dnition de la relation de composition qui soit e proche du code source Notre objectif est danalyser la smantique de la relation de composition et dtudier e e les direntes formes de son implmentation dans les programmes Java pour pouvoir fore e muler des proprits et des contraintes qui nous permettent de lidentier statiquement ee dans des programmes Java. Nous distinguons deux probl`mes, le premier concerne la e dnition de la relation de composition dans un langage de programmation et le deuxi`me e e concerne lidentication et la validation de la relation de composition entre deux objets dans un programme donn. Dans notre tude, nous proposons une dnition de la ree e e lation de composition et nous prsentons un algorithme, bas sur cette dnition, pour e e e identier statiquement les relations de composition dans des programmes Java. Nous estimons que notre dnition est simple, abstraite et indpendante de la syntaxe du e e langage de programmation ; nous prsentons une solution qui est directement lie aux e e probl`mes dimplmentation des relations de composition dans le code source et nous e e proposons un algorithme pour identier statiquement ces relations. Cependant, nous ne nous concentrons pas sur les probl`mes lis aux direntes smantiques de la relation de e e e e composition. 1.3 Contributions : une nouvelle approche pour dnir et identier statie quement les relations de composition dans des programmes Java Il est dicile, par une analyse statique ou dynamique, de vrier et de valider dune e mani`re sre que la relation de composition dnie entre deux classes sera respecte e u e e dans le programme. Une solution simple consiste ` sassurer que la cration des parties a e

3 est faite par des mthodes dnies dans le tout et ` limiter lacc`s de ces mthodes e e a e e au tout (implicitement, les parties sont compl`tement englobes par le tout). Il sut e e dans ce cas dannoter le champ concern par la relation de composition comme tant e e un composant et on peut vrier statiquement que la relation de composition est valide e pour toutes les excutions possibles du programme. Cette solution est tr`s contraignante e e et limine beaucoup de cas tr`s utiliss dans la pratique. Par exemple, une partie nest e e e pas ncessairement cre par son tout ; elle peut tre cre ailleurs. Aussi, en pratique, on e ee e ee accepte lacc`s direct ` une partie pour accder ` ses champs et invoquer ses mthodes. e a e a e Cest pourquoi nous tudions la relation de composition pour lui donner une dnition e e proche de limplmentation. Lapport principal de notre dnition est quelle ore une e e grande exibilit pour lintgrer dans le langage de programmation, par exemple sous e e forme dannotations : en plus de lavantage que les rsultats de lanalyse peuvent tre e e expliqus et justis facilement par les programmeurs, ces derniers peuvent modier e e directement le code pour ajouter des annotations pour explicitement indiquer quune rfrence correspond ` une relation de composition par exemple. ee a 1.4 Organisation du mmoire e Le reste de ce mmoire est organis comme suit : le chapitre 2 prsente un tat e e e e de lart des principaux tudes et travaux connexes qui ont propos des dnitions et e e e des implmentations pour identier la relation de composition. Le chapitre 3 prsente e e notre dnition de la relation de composition ; nous expliquons avec des exemples les e dirents cas de programmes o` une relation de composition peut tre identie. Nous e u e e tudions dans le chapitre 4 les direntes contraintes que nous imposons sur lutilisation e e des rfrences pour pouvoir identier et vrier la relation de composition. Le chapitre ee e 5 prsente notre implmentation et le chapitre 6 discute des rsultats de nos tests ainsi e e e que des limitations observes. Enn, nous concluons ce mmoire et proposons de futures e e directions de recherche.

CHAPITRE 2

ETAT DE LART

2.1

Les relations entre les classes : association, agrgation et composition e Dans UML, les relations entre les classes sont une abstraction des liens qui lient les

instances de ces classes. Ces liens orent la possibilit aux objets de communiquer entre e eux ; un objet li ` un autre objet peut accder ` ses champs et invoquer ses mthodes. ea e a e Chaque type de relations entre deux classes dnit des proprits prcises sur les liens e ee e qui associent les objets concerns et peut ainsi limiter leurs interactions avec les autres e objets du programme : la relation dassociation est la forme de base pour dnir une relation entre deux e classes ; elle exprime la capacit dun objet dune classe ` envoyer un message ` e a a objet de lautre classe ; la relation dagrgation est une forme particuli`re de la relation dassociation qui e e exprime un couplage entre les classes ; elle permet de reprsenter des relations tout e partie [Mul97] ; la relation de composition est une forme particuli`re de la relation dagrgation e e o` une partie doit appartenir au plus ` un tout. Un tout est responsable de la u a destruction de ses parties quand il est lui-mme dtruit [Gro07]. e e 2.1.1 Dnition de la relation de composition dans UML e

Ainsi, selon la spcication UML 2.1.2 [Gro07] : e Une relation de composition est une forme tr`s forte de la relation dagrgation e e qui ncessite que linstance dune partie soit incluse au plus dans un tout ` un e a moment donn. Si le tout est supprim, toutes ses parties sont normalement e e supprimes avec lui. Une partie peut (l` o` permis) tre enleve du tout avant e a u e e

5 que celui-ci ne soit supprim et ainsi ne pas tre supprime comme partie du e e e tout. Cette dnition se focalise sur les objets et nous lexprimons autrement comme suit : e une classe T est en relation de composition avec une classe P si chaque instance de la classe T dtient, ` un moment donn, lunique rfrence vers une instance de la classe e a e ee P. Si linstance de la classe T est supprime alors linstance de la classe P doit tre aussi e e supprime. e Les aspects importants de cette dnition sont : e la partie peut tre lie ` dautres objets mais pas ` un autre tout au mme moment : e e a a e par exemple, une voiture (tout) poss`de quatre roues (parties) et il est impossible e quune roue soit partage entre deux voitures mais une roue peut tre enleve e e e temporairement de la voiture pour des raisons dentretien ; la partie peut tre dtache du tout : par exemple, les roues dune voiture peuvent e e e tre enleve dune voiture et attache ` une autre voiture. Cet aspect est dlicat ` e e e a e a implmenter et nous nen proposons pas une solution dans notre implmentation. e e Booch et al. [BRJ98] soulignent de plus que les parties peuvent tre cres apr`s la e ee e cration du tout ; de mme les parties peuvent tre explicitement enleves avant la dese e e e truction du tout. Nous mentionnons que nous nessayons pas, dans ce mmoire, de prendre e position par rapport aux divergences que peuvent poser ces particularits. e 2.1.2 Exemple dimplmentation de la relation de composition en Java e

Typiquement, limplmentation, avec Java, de la relation toutpartie est faite en e dclarant, dans la classe qui reprsente le tout, un champ (simple, tableau ou collection) e e dont le type est celui de la classe qui reprsente la partie. Une relation toutpartie entre e les classes T et P est implmente dans lexemple suivant : e e
1 2 3 4 5

class P {} class T { private P p = new P(); ... }

6 Cependant, cette dclaration est insusante pour pouvoir armer une relation de come position entre les classes T et P. Nous pouvons infrer une relation de composition entre e les classes T et P si et seulement si : les mthodes dnies dans T utilisent le champ p uniquement pour invoquer direce e tement les mthodes de P ; sans retourner ou passer en param`tre la rfrence sur e e ee P ` un autre contexte ; a lorsque le modicateur du champ p est de type protected ou default, la condition cidessus nest viole par aucune des sousclasses de T qui rednissent ses mthodes e e e ou dnissent de nouvelles mthodes qui utilisent ce champ. e e Dans les autres cas, par exemple, o` la rfrence de P est passe en param`tre ou reu ee e e tourne ` un autre contexte, ou lorsque le modicateur de la variable p est de type e a public, linfrence de la relation de composition devient dicile et ncessite des analyses e e plus complexes (nous prsentons dans les chapitres suivants notre approche pour grer e e ces cas). 2.2 Proprits de la relation toutpartie e e Plusieurs travaux de recherche ont t mens pour formaliser les direntes proprits ee e e ee de la relation toutpartie, notamment dans le domaine de la reprsentation des connaise sances, des ontologies et du gnie logiciel. Winston et al. [WCH87] sont les premiers ` e a proposer une classication des smantiques de la relation entre un tout et ses parties. Ils e proposent six types de relation toutpartie et les classent suivant trois proprits : ee fonctionnalit : proprit qui indique si la relation dune partie avec un tout est e ee fonctionnelle ou non ; homomrie : proprit qui indique si les parties sont ou non homom`res ; e e ee e e sparabilit : proprit qui indique si la partie et le tout sont sparables. e e ee e Barbier et al. [BHSPLB03] prsentent une extension de UML 1.4 et introduisent un e fragment de mtamod`le pour la relation toutpartie bas sur trois mta-classes : Wholee e e e Part, Aggregation et Composition. Ils reprennent les proprits primaires et secondaires ee

7 de la relation toutpartie introduites par Kilov [Kil99] et les formalisent en utilisant OCL : proprits primaires : toutpartie (nature binaire), proprit mergeante, proprit ee e ee ee rsultante, asymtrie au niveau instance, antisymtrie au niveau type ; e e e proprits secondaires : encapsulation, chevauchement des dures de vie (9 cas), ee e transitivit, partageabilit, congurabilit, sparabilit, mutabilit, et dpendance e e e e e e e existentielle. Gensel et al. [GCGZ06] proposent une intgration des diverses smantiques de la e e relation toutpartie. Ils proposent une extension du mtamod`le AROM et distinguent e e agrgation et composition ainsi quun certain nombre de proprits primaires et secone ee daires. Cependant, ils norent pas de formalisation de leurs proprits. Dans leur article, ee ils distinguent trois types principaux de relations toutpartie : relation de type agrgation : sa principale proprit est la partageabilit, ce qui e ee e veut dire quune partie peut appartenir ` plusieurs tout ; a relation de type appartenance : un cas particulier de lagrgation, dont la principale e proprit est la sparabilit, ce qui veut dire que la partie est sparable de son tout ; ee e e e relation de type composition : ce type de relation nadmet pas la partageabilit, e donc une partie doit ncessairement appartenir ` un seul tout. e a 2.3 Analyse de pointeurs Lanalyse de pointeurs (pointer analysis) permet destimer lensemble des locations en mmoire sur lesquelles les pointeurs peuvent pointer. Elle permet donc de dterminer e e les locations en mmoire qui peuvent tre accessibles avec plus dun seul moyen [Muc97]. e e Cest un outil important, pour les compilateurs, pour eectuer correctement la majorit e des optimisations [Muc97]. Dans notre mmoire, nous utilisons lanalyse de pointeurs e pour dterminer les points du programme o` des variables rfrencent la mme location e u ee e en mmoire ; lanalyse des rfrences de ces variables nous permet, comme nous allons le e ee

8 dtailler dans la suite de ce mmoire, de vrier si une relation de composition existe ou e e e non. Lhotk dans son mmoire [Lho02] dtaille les dirents travaux faits pour amliorer a e e e e lecacit et la prcision des analyses de pointeurs avec les langages C et Java. Il cite e e en particulier le travail dEmami et al. [EGH94] qui introduit une analyse pointe-sur (point-to analysis) pour les structures de donnes alloues dans la pile. Lanalyse est e e sensible au contexte (contexte sensitive) et utilise le concept des locations abstraites de la pile pour saisir toutes les relations possibles entre les locations accessibles dans la pile. Elle calcule les ensembles (pointe-sur ensemble) des variables sur lesquelles un pointeur peut pointer. Andersen [And94] propose une analyse pointe-sur pour le langage de programmation C. Cette analyse est insensible au contexte et au ot mais prsente une bonne e modlisation de la mmoire dynamique (tas). Limplmentation utilise des contraintes e e e pour reprsenter les donnes de lanalyse et vise ainsi ` rsoudre ces contraintes. e e a e 2.4 Infrence de lunicit des rfrences e e ee Dans les tudes concernant la gestion de la mmoire et linfrence dunicit, la rfrence e e e e ee est dnie comme tant unique sil nexiste pas dautres locations en mmoire qui rfrencent e e e ee le mme objet [CR07]. e Cherem et al. [CR07] proposent un algorithme pour infrer lunicit des rfrences e e ee dans un programme Java ; si la rfrence dun champ est unique dans un programme, ee lalgorithme ajoute un destructeur explicite pour ce champ aussitt quil rf`re un autre o ee objet. Ils eectuent une analyse de pointeurs de type must-alias qui permet de savoir prcisment ` chaque point du programme quels sont les objets rfrencs par les variables e e a ee e (et les champs) [Muc97] ; leur algorithme eectue, dans une premi`re tape, une analyse e e intra-procdurale (ow sensitive must-alias) pour chaque mthode et par la suite eece e tue une analyse inter-procdurale (ow insensitive) pour construire des ensembles des e rfrences vers un objet. Si lensemble contient une seule rfrence, alors cette rfrence ee ee ee est unique. Leur algorithme permet le partage temporaire dune rfrence avec dautres ee champs ` lintrieur dune mthode sil est prouv que ces champs sont vraiment uniques a e e e

9 a ` lappel et ` la sortie de la mthode. Typiquement, cela est pratique pour les structures a e de donnes qui gardent des rfrences sur des objets ; si le partage est unique ` lintrieur e ee a e des mthodes dnies dans ces structures de donnes alors il est possible dy ajouter des e e e destructeur pour librer les objets rfrencs. e ee e Ma et al. [MF07] prsentent aussi un algorithme pour infrer lunicit des rfrences e e e ee dans des programmes Java ; leur implmentation utilise une analyse de pointeurs locale e combine avec une analyse interprocdurale base sur des contraintes. Lanalyse intrae e e procdurale est sensible au ot pour les variables locales mais insensible au ot pour les e champs. Laectation aux champs est limite aux champs de lobjet courant ; les autres e aectations aux champs dun objet externe ou aux champs statiques sont considres ee automatiquement comme une violation de la proprit dunicit. ee e 2.5 Identication de la relation de composition La dnition et limplmentation des algorithmes pour linfrence de la relation de e e e composition sont lobjet de plusieurs travaux de recherche. Notamment, Guhneuc et e e al. [GAA04] prsentent une dnition formelle de la relation de composition base prine e e cipalement sur les proprits dexclusivit et de dure de vie : ee e e lexclusivit exprime la possibilit pour un objet dtre rfrenc par un ou plusieurs e e e ee e autres objets ` un moment donn. Une instance de B est dite exclusive ` une a e a instance de A si linstance de B nest pas rfrence par dautres instances au ee e mme moment ; cela ne devrait pas donc exclure le transfert dexclusivit. Dans le e e cas dune relation de composition entre A (le tout) et B (la partie), une instance de B doit tre exclusive ` une instance de A, mais le cas inverse nest pas ncessaire ; e a e la dpendance existentielle exprime une contrainte sur la dure de vie de linstance e e dune classe par rapport ` la dure de vie de linstance de la classe ` laquelle elle a e a est lie. Dans le cas dune relation de composition entre A et B, une instance de B e ne peut pas vivre plus longtemps que linstance correspondante de A. En pratique, cela exclut donc la possibilit de transfert dexclusivit. e e

10 Leur implmentation est base sur une analyse dynamique pour infrer la relation de e e e composition entre deux classes ; ils utilisent une technique danalyse de la trace pour saisir les vnements de lexcution du programme (lecture de la valeur dun champ, destruction e e e dune instance et n du programme). Lanalyse de ces vnements est faite avec des e e prdicats (Prolog) dont le calcul donne des valeurs pour les proprits dexclusivit et de e ee e dure de vie et qui permettent ainsi dinfrer des relations de composition. e e Kollmann et al. [KG01] prsentent galement une dnition de la relation de compoe e e sition base sur les proprits de strong ownership et de co e ee ncidence de dure de vie : e le strong ownership ncessite quune partie soit incluse dans un seul tout. Cette proe prit est une forme forte dexclusivit qui nadmet pas les rfrences temporaires ee e ee et le transfert dunicit ; e la co ncidence de dure de vie ncessite que linitialisation du tout soit faite avant e e linitialisation des parties et que la destruction des parties soit faite, au plus tard, au moment de la destruction du tout. Ils proposent des algorithmes, utilisant aussi lanalyse dynamique, pour la dtection de e ces proprits. Ils vrient ` chaque cration dun nouvel objet si des rfrences vers des ee e a e ee objets existants ont t tablies et les excluent du groupe des parties potentielles. Ils ee e vrient aussi pour tous les nouveaux objets si le nombre de rfrences est infrieur ` e ee e a 2, sinon ils seront exclus. Tous les objets rfrencs dont la dure de vie dpasse celle ee e e e ` des objets qui les rfrencent sont exclus aussi. A la n du programme, ils inf`rent une ee e relation de composition pour les objets qui nont pas t exclus. ee La vrication des proprits dexclusivit (ou non partageabilit) et de dpendance e ee e e e de dure de vie de la partie avec un tout prsentent des limitations ; les implmentations e e e utilisant uniquement la proprit de dpendance de dure vie sont moins performantes [YSC+ 05]. ee e e Aussi, il nest pas possible avec ces analyses didentier les cas o` la partie est rfrence u ee e par des objets qui sont, eux mmes, parties du tout, ou didentier le cas o` la partie est e u utilise dans le contexte des patrons de conceptions itrateurs, dcorateurs et fabriques o` e e e u les rfrences vers les parties sont souvent temporaires [Mil05]. Une autre limitation est ee que les rsultats obtenus ` partir de lanalyse dynamique ne peuvent pas tre gnralises e a e e e e

11 pour toutes les excutions [Ern03; JR00]. e Pour remdier ` ces probl`mes, Milanova [Mil05] prsente une dnition de la relation e a e e e de composition base sur le mod`le du tout dominateur (owners-as-dominators model ) e e qui ne ncessite pas de relation exclusive des parties avec le tout ; dans ce mod`le, la e e notion de dominance dun nud sur les autres nuds dans un graphe permet de dnir e une fronti`re dacc`s ` un objet et par consquent dignorer les appels ` lintrieur de e e a e a e cette fronti`re. e Un nud m domine un nud n si chaque chemin de la racine du graphe qui atteint le nud n doit passer par le nud m. Le nud m domine immdiatement e le nud n si m domine n et il nexiste pas de nud p tel que m domine p et p domine n [Mil05]. Limplmentation de cette approche utilise lanalyse de pointeurs qui op`re sur des e e programmes incomplets (fragment points-to analysis) ; lanalyse proc`de en crant une e e mthode main qui approxime toutes les excutions possibles du programme. Le rsultat e e e de cette analyse est un graphe qui approxime tous les graphes possibles dun objet ` a lexcution ; ce graphe est une abstraction statique de la mmoire dynamique (tas) ` e e a lexcution o` chaque nud correspond ` un objet et les arcs entre ces nuds core u a respondent aux rfrences entre ces objets. Lanalyse ensuite utilise ce graphe pour ee dterminer pour chaque nud m la fronti`re du sous graphe dont la racine est ce nud. e e Si le nud n est visible uniquement dans le sous-graphe dont la racine est m alors une relation de composition est identie. Lapproche de Milanova se distingue par lutilisation e de lanalyse statique et la possibilit danalyser des programmes incomplets. e

CHAPITRE 3

NOTRE DEFINITION DE LA RELATION DE COMPOSITION

3.1

Dnitions : variable, rfrence et objet e ee Un nom de variable dans un programme dsigne un emplacement ou une location e

particuli`re en mmoire ` lexcution ; plus prcisment, la valeur dune variable, ` e e a e e e a lexcution, est une rfrence sur une location particuli`re en mmoire (nous excluons e ee e e de cette dnition les variables de type primitives int, char, ...). La lecture de cette valeur e correspond ` la cration dune nouvelle copie de la rfrence sur la location en mmoire a e ee e rfrence par cette variable. Par exemple, linstruction suivante : ee e
1

x = y;

permettra aux deux variables y et x de rfrencer la mme location en mmoire, chacune ee e e aura une copie de la rfrence. ee Dpendamment du contexte et du ot de contrle, une variable peut, au cours de e o lexcution, rfrencer direntes locations en mmoire ` dirents points du programme. e ee e e a e De mme, une location en mmoire peut tre rfrence par plusieurs variables. Il est donc e e e ee e important de distinguer les rfrences dans un programme : ee
1 2

x = y; x = z;

En eet, la rfrence contenue dans la variable x ` la ligne 1 peut tre dirente de la ee a e e rfrence contenue dans x ` la ligne 2. ee a Nous tudions plus en dtails dans les sections suivantes limportance pour notre e e approche de distinguer les rfrences dans le programme et nous prsentons dans les chaee e pitres suivants les dirents cas qui ncessitent une reprsentation spciale des rfrences. e e e e ee Dans le contexte du langage Java, nous pouvons dire indiremment quune variable e rfrence ou pointe sur une location particuli`re en mmoire. Dans ce qui suit, nous ee e e utiliserons la terminologie suivante : variable : pour dsigner une variable locale (dclare dans une mthode) ; e e e e

13 champ : pour dsigner une variable de classe (statique) ou dinstance ; e objet (ou instance) : pour dsigner une location particuli`re en mmoire ; e e e copie de la rfrence : pour dsigner la rfrence contenue dans une variable ou un ee e ee champ ` un point du programme. a 3.2 Notre dnition de la relation de composition e Une relation entre deux classes A et B est dite de composition si on peut prouver que la rfrence est unique entre les instances de ces deux classes : si A dclare un champ b de ee e type B, alors la rfrence contenue dans b doit tre unique (si une instance de A doit tre ee e e supprime de la mmoire alors linstance de B rfrence par b doit tre aussi supprime). e e ee e e e Lunicit de la rfrence ne doit pas exclure lexistence dautres rfrences temporaires, e ee ee ainsi une rfrence peut tre : ee e unique : dans ce cas linstance rfrence a un parent principal qui, si supprim, ee e e implique que cette instance doit tre aussi supprime (ceci est vrai mme sil y a e e e dautres rfrences sur cette instance, qui doivent tre dans ce cas temporaires) ; ee e temporaire : une rfrence est dite temporaire, sil ne peut exister un point du ee programme o` cette rfrence est utilise apr`s la suppression, dans la mmoire, de u ee e e e linstance rfrence ; ee e normale : en prsence de plus dune rfrence non temporaire, aucune rfrence ne e ee ee peut tre qualie dunique ; dans ce cas ces rfrences sont considres normales e e ee ee et linstance rfrence na pas de parent connu. ee e Le probl`me principal de cette dnition est didentier les cas o` une rfrence peut e e u ee tre considre temporaire. Milanova [Mil05] identie deux cas o` la rfrence vers une e ee u ee instance est ignore parce quelle est considre comme une sorte de relation dacc`s e ee e temporaire : le premier cas dutilisation temporaire dune rfrence est celui o` un objet est cr ee u ee dans un contexte et retourn, sans tre utilis, ` un autre contexte ; cela correspond e e e a

14 a ` dire que la mthode cratrice renvoie une rfrence unique. Par exemple, si un e e ee objet est cr et retourn immdiatement (i.e., return new Object()), ou pass ` ee e e ea un autre contexte (i.e., new FileWriter(new File())), cela implique que dans le code du constructeur, la rfrence this est aussi temporaire ; ee le deuxi`me cas dutilisation temporaire dune rfrence concerne lacc`s local ` un e ee e a champ ; la rfrence obtenue nest pas renvoye ` un autre contexte (aecte ` un ee e a e a champ, passe en param`tre dune mthode ou retourne). Ce cas est tr`s utile e e e e e pour accder aux champs ou invoquer des mthodes dnies dans la classe de la e e e rfrence. ee Il est important de mentionner que laspect temporaire dune rfrence concerne sa ee dure de vie uniquement dans le contexte o` elle est utilise. Autrement dit, il se peut e u e quune rfrence soit considre comme temporaire mais sa dure de vie est relative ee ee e au temps dexcution du programme (par exemple, une variable qui est dnie dans e e la mthode principale du programme main va exister le temps dexcution de tout le e e programme). 3.3 Exemples de relations de composition Cette section prsente des exemples dimplmentation de la relation de composition e e et explique pour chaque exemple les conditions pour lesquelles nous pouvons armer (ou non) la prsence dune relation de composition. e 3.3.1
1 2 3 4 5 6 7 8 9 10 11

Exemple 1 : porte dune rfrence e ee

class B {} class A { private B b1 = new B(); } class CompositionExample1 { void main () { A a1 = new A(); } }

15 La rfrence vers linstance de A dans la mthode main est sauvegarde dans une ee e e variable locale ; cette variable sera supprime de la pile ` la sortie de la mthode main. e a e Linstance de A pourra alors tre libre de la mmoire ; la machine virtuelle pourrait e ee e donc supprime cette instance lors du ramassage des miettes (garbage collection) des e objets en mmoire puisquil ny a pas dautres rfrences dessus. Linstance de B sera aussi e ee susceptible dtre libre de la mmoire vu que la rfrence de B dans A est sauvegarde e ee e ee e dans un champ dont le modicateur est priv (private) et elle nest pas aecte ou e e retourne ` un autre contexte ` lextrieur de A (ceci est vrai mme si on suppose que e a a e e cet exemple fait partie dun programme qui contient dautres lignes du code en dehors de A et B. De mme si A devait avoir des sous-classes, la rfrence contenue dans b1 ne e ee peut tre modie. On peut donc dduire une relation de composition entre la classe A e e e et la classe B. 3.3.2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

Exemple 2 : rfrence temporaire sur un objet ee

class B {} class A { private B b1; public void setB(B b) { this .b1 = b; } } class CompositionExample2 { void main() { B b2 = new B(); A a1 = new A(); a1.setB(b2); } } De mme que dans lexemple prcdent, linstance de A est susceptible dtre libre de e e e e ee

la mmoire ` la sortie de la mthode main puisquil ny a aucune autre rfrence dessus. e a e ee Linstance de B cre ` la ligne 10 est rfrence par le champ b1 et la variable b2, mais ee a ee e la variable b2 sera supprime de la pile, par consquent linstance de B sera rfrence e e ee e uniquement par linstance de A. On peut donc dduire une relation de composition entre la e

16 classe A et la classe B. Dans cet exemple, linstance de B (composant) est cre ` lextrieur e a e de A (objet composite) et avant la cration de linstance de A. e 3.3.3
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

Exemple 3 : rfrences non-temporaires sur un objet ee

class B {} class A { public static B b1; } class C { public static B b2; } class CompositionExample3 { void main() { B b3 = new B(); A.b1 = b3; C.b2 = b3; } } Dans cet exemple, ` la sortie de la mthode main, la variable b3 sera supprime de la a e e

pile, donc linstance de B cre ` la ligne 10 sera rfrence par les champs b1 de A et b2 ee a ee e de C. Nous pouvons armer quil ny a pas de relation de composition entre les classes A et B dun ct ni entre les classes C et B dun autre cot. oe e 3.3.4
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Exemple 4 : rfrences entre composants du mme objet composite ee e

class B {} class A { private B b1; private C c1 = new C(); public void setB(B b) { this .b1 = b; c1.setB(b); } } class C { private B b2;

17
16 17 18 19 20 21 22 23 24 25 26 27

public void setB(B b) { this .b2 = b; } } class CompositionExample4 { void main() { B b3 = new B(); A a1 = new A(); a1.setB(b3); } } Dans cet exemple, ` la sortie de la mthode main, linstance de B sera rfrence a e ee e

dans A et C et linstance de C sera rfrence uniquement dans A, donc, on peut dduire ee e e une relation de composition entre la classe A et la classe C mais il ny a pas de relation de composition entre la classe C et la classe B. Par contre, lorsque la machine virtuelle rclamera linstance de A, elle pourra rclamer linstance de C et celle de B. On peut donc e e dduire aussi une relation de composition entre la classe A et la classe B. En fait, cest un e cas plus dlicat qui nest pas inclus dans toutes les dnitions de composition, et pas e e dans la ntre. o 3.4 Modlisation de la relation de composition e Notre approche pour modliser la relation de composition entre deux classes A et B e consiste ` annoter la rfrence entre ces deux classes avec un descripteur dunicit. Ce a ee e descripteur dunicit est dni en fonction des deux proprits suivantes : e e ee exclusive ; transitoire. Lexclusivit est une proprit qui distingue une rfrence particuli`re des autres e ee ee e rfrences au mme objet ; au plus une rfrence sur un objet donn peut tre exclusive. ee e ee e e Cette proprit est ncessaire mais pas susante pour garantir lunicit ; il faut que toutes ee e e les autres rfrences soient transitoires. Si on consid`re lensemble des rfrences possibles ee e ee sur un objet, une rfrence peut tre dnie comme tant : ee e e e exclusive : la rfrence est exclusive si toutes les autres rfrences sont transitoires ; ee ee

18 transitoire : la rfrence est considre temporaire ; elle ne peut pas empcher la ee ee e suppression de lobjet rfrenc et donc nalt`re pas la proprit dunicit ; ee e e ee e non-exclusive et non-transitoire : la rfrence est considre normale ; elle empche ee ee e de conclure une relation de composition ; exclusive et transitoire : cas dgnr et inintressant o` toutes les rfrences sur e e ee e u ee un objet sont considres comme transitoires. ee

CHAPITRE 4

DEFINITION DES CONTRAINTES SUR LUTILISATION DES REFERENCES

Notre approche pour identier une relation de composition entre deux classes A et B est base sur la vrication de lunicit de la rfrence entre A et B. Dans lexemple suivant, e e e ee si nous voulons vrier que le champ b de la classe A correspond ` une implmentation de e a e la relation de composition entre A et B, alors nous devons valider que toutes les rfrences ee que peut contenir le champ b, ` lexcution, sont uniques. a e
1 2 3 4 5 6 7 8 9 10

class B {} class A { B b; void main() { A a = new A(); B b1 = new B(); a.b = b1; B b2 = a.b; } } Par exemple, ` la ligne 6 du programme ci-dessus, on cre une nouvelle instance de a e

` type B (la rfrence vers cette instance est sauvegarde dans b1). A la ligne 7, on cre ee e e une nouvelle copie de la rfrence sur la mme instance (sauvegarde dans b). De mme, ee e e e a ` la ligne 8, on cre une nouvelle copie de la rfrence sur la mme instance (sauvegarde e ee e e dans b2). Lide de base de notre approche est de grer ces copies de rfrences qui rfrencent la e e ee ee mme instance et dimposer des contraintes sur leurs proprits (exclusive et transitoire) ; e ee ces contraintes sont typiquement dnies ` tout point du programme o` on cre une e a u e nouvelle copie dune rfrence. ee Dans ce chapitre nous tudions en dtails les proprits exclusive et transitoire des e e ee rfrences et nous prsentons les contraintes que nous avons dnies sur ces proprits ee e e ee et leur analyse. Nous prsentons aussi les direntes instructions du langage Java qui e e permettent de crer une nouvelle copie dune rfrence. e ee

20 4.1 Analyse de la relation de composition Cette section prsente notre analyse et explique les direntes transformations que e e nous appliquons sur les instructions du code Java. Nous exprimons une partie simplie e du langage Java comme suit : var = exp ; avec : var ::= r | r.f exp ::= var | new C | invoke r.m(p0 , p1 , ...) | null o` : u r ( ` lensemble des noms de variables V) : reprsente une variable (inclut les a e param`tres de mthodes p0, p1, ...) ; e e f ( ` lensemble des noms de champs F) : reprsente un champ ; a e C : reprsente une classe ; e m ( ` lensemble des noms de mthodes M) : reprsente une mthode ; a e e e invoke : la spcication de la machine virtuelle Java dnit quatres primitives pour e e les appels de mthodes invokevirtual, invokestatic, invokespecial et invokeinterface. e Nous allons prsenter dans le chapitre suivant les dtails que dnit chaque primitive e e e (nous signalons que ces primitives sont visibles au niveau du bytecode Java). La syntaxe du langage prsente ci-dessus exprime une vue globale et simplie du lane e e gage Java que nous traitons dans notre analyse (nous nous intressons particuli`rement e e aux direntes instructions du langage Java qui permettent de crer une nouvelle copie e e dune rfrence) ; nous ajouterons des dtails dans les sections suivantes pour expliquer ee e comment nous grons les autres lments du langage Java comme les tableaux, les struce ee tures de contrle (if-else), les types et les exceptions. o 4.1.1 Reprsentation du code source Java e

Notre analyse se base sur la reprsentation SSA du code source Java (static single e assignment) ; SSA est une reprsentation intermdiaire qui garantit une dnition stae e e

21 tique unique pour chaque variable [CFR+ 91]. Ainsi, une variable ne sera modie quune e seule fois : si, dans le programme, on aecte plusieurs valeurs ` la mme variable alors a e la reprsentation SSA va crer de nouvelles variables pour sauvegarder les direntes e e e valeurs. SSA permet davoir une variable distincte pour chaque nouvelle rfrence vers ee un objet. Le programme suivant :
1 2

x = y; x = z;

sera remplac par : e

1 2

x1 = y; x2 = z;

Dans le reste de ce chapitre, toutes les transformations du code Java correspondent ` la a reprsentation intermdiaire telle que dnie par Shimple (chapitre 5) ou ` lextension, e e e a nous le mentionnerons explicitement, que nous avons ajoute ` cette reprsentation. e a e Dans le cas o` une variable pourrait provenir de plusieurs points du programme : u
1 2 3 4 5 6

if (y = null ) { x = y; } else { x = z; } w = x;

SSA nous permet didentier les dirents points du programme o` la variable a t e u ee dnie ; elle cre des nuds qui listent tous les points du programme o` la valeur e e u dune variable est susceptible dtre modie ` lexcution du programme : e e a e
1 2 3 4 5 6 7

if (y = null ) { x1 = y; } else { x2 = z; } x3 = (x1, x2); w = x3;

ainsi, la variable x3 peut, dpendamment du ot du contrle, avoir la valeur contenue e o dans la variable x1 ou avoir la valeur contenue dans x2. Le fait davoir un nouveau nom de variable pour chaque aectation est tr`s important. e Cela nous permet de considrer chaque variable comme une rfrence distincte sur un e ee

22 objet. Nous avons besoin aussi de distinguer les direntes lectures dune variable. Chaque e lecture dune variable implique un partage de la rfrence avec une autre variable, donc ee les proprits dunicit peuvent tre direntes ` la prochaine lecture. Nous avons tendu ee e e e a e la reprsentation SSA pour supporter ce cas particulier. Par exemple, le code suivant ne e sera pas modi par SSA : e
1 2 3

x = y; z = y; w = y;

Notre analyse transformera ce code en :

1 2 3

x = y#1 ; z = y#2 ; w = y#3 ;

pour nous permettre de distinguer les proprits de la rfrence contenue dans la variable ee ee y aux dirents points du programme. Par exemple, les proprits de la rfrence contenue e ee ee dans la variable y ` la ligne 2 dpendent de linstruction de la lecture de la valeur de a e y ` la ligne 1. De mme les proprits de la rfrence de y ` la ligne 3 dpendent de a e ee ee a e linstruction de la lecture de la valeur de y ` la ligne 1. Il est important de mentionner a que les numros associs ` la variable y naectent pas la rfrence contenue dans cette e e a ee variable, plutt, ces numros permettent de distinguer les dirents points du programme o e e o` on lit la valeur de cette variable et donc pouvoir exprimer des proprits direntes u ee e de la rfrence aux dirents points du programme. ee e Un cas particulier est celui o` on lit la valeur de la variable dans une structure de u contrle : o
1 2 3 4 5 6

if (v = null ) { x = y; } else { z = y; } w = y;

ce code sera transform en : e

1 2

if (v = null ) { x = y#1 ;

23
3 4 5 6 7

} else { z = y#2 ; } y#3 = (y#1 , y#2 ); w = y#3 ; Notre analyse nous permet de reprsenter le code en fonction des rfrences contenues e ee

dans les variables et ainsi nous donne une approximation de ltat de la mmoire ` e e a ` lexcution. A partir de cette reprsentation, nous construisons des liens qui indiquent e e des dpendences et induisent des contraintes sur les copies dune rfrence, par exemple, e ee si on consid`re le programme suivant : e
1 2

x = y#1 ; z = y#2 ;

nous allons crer alors les liens de contrainte suivants : e ligne 1 : un lien entre les rfrences des variables y (ry#1 ), x (rx ) et y (ry#2 ) (pour ee des raisons de simplicit nous allons crire, dans ce qui suit, rx pour dsigner la e e e rfrence de la variable x, ou ry#1 pour dsigner la rfrence de la variable y ` un ee e ee a point du programme, dans ce cas ` la ligne 1) ; a ligne 2 : un lien entre ry#2 et rz . Dans notre implmentation, les liens correspondent ` une structure de donnes qui e a e regroupe les rfrences associes par les instructions que nous allons dtailler ci-dessous ee e e (seules ces instructions sont considres lors de la cration des liens entre les rfrences). ee e ee Les rfrences associes par un lien rfrencent le mme objet, ainsi, comme nous ee e ee e allons lexpliquer dans le chapitre suivant, nous pouvons exprimer des contraintes sur les proprits de ces rfrences. Nous expliquerons aussi dans ce chapitre pourquoi nous ee ee avons associe les rfrences de la variable y aux points du programme 1 et 2 avec la e ee rfrence de la variable x. ee 4.1.2 Instructions daectation

Instruction de copie x = y : nous crons un lien entre ry et rx ; e Lecture dun champ x = y.f : nous crons un lien entre rf et rx ; e

24 Ecriture dans un champ x.f = y : nous crons un lien entre ry et rf . e 4.1.3 Cration dobjet : T x = new T() e

Nous crons une variable spciale pour reprsenter lopration dinstanciation. e e e e Le programme suivant :
1

a = new T();

sera remplac par celui ci : e

1 2 3

x = new T; invoke x.T.init (); a = x;

Donc, notre analyse va crer les liens suivants : e ligne 1 : un lien entre rx et new T ; ligne 3 : un lien entre ra et rx . Dans notre implmentation, nous remplaons le new T par un nom de varaible unique e c pour tout le programme. Le new nous permet de propager les proprits de la rfrence ee ee de faon cohrente avec notre approche de rsolution de contraintes. Le new est considr c e e ee comme une rfrence spciale qui est unique au point du programme o` elle est utilise ee e u e mais temporaire apr`s ce point du programme. e ` A la ligne 2, linvocation du constructeur de la classe T est gre de la mme mani`re ee e e quun appel dune mthode standard. e 4.1.4 Nullication : T x = NULL

Nous crons une variable spciale pour reprsenter lopration de nullication associe e e e e e a ` une variable x. Le NULL nous permet de propager les proprits de la rfrence de ee ee faon cohrente avec notre approche de rsolution de contraintes. Le NULL est considr c e e ee comme une rfrence spciale qui est unique au point du programme o` elle est utilise ee e u e mais temporaire apr`s ce point du programme. e

25 4.1.5 Appel de mthode : invoke r.m(p0, p1, ...) e

Dans le cas dun appel de mthode, on lie toutes les variables passes en param`tres e e e avec les param`tres formels de la mthode. Dpendamment du ot de contrle, une e e e o mthode peut retourner plusieurs valeurs ` dirents points du programme, on lie donc e a e toutes les variables retournes par la mthode avec la variable quon lui aecte la valeur. e e Prenons lexemple suivant :
1 2 3 4 5 6 7

T bar(T obj) { return obj; } void main() { T y = new T(); T x = bar(y); }

Le programme prcdent sera remplac par (simpli pour des raisons de lisibilit) : e e e e e
1 2 3 4 5 6 7 8 9 10

void main() { w1 := @this; y = new T; x = invoke w1.bar(y); } java .lang.Object bar(T) { w2 := @this; w3 := @parameter0: T; return w3; }

et notre analyse va crer les liens suivants : e ligne 2 : un lien entre r@this et rw1 ; ligne 3 : un lien entre rnew java.lang.Object et ry ; ligne 4 : un lien entre rw1 et r@this ; ligne 4 : un lien entre ry et r@parameter0 ; ligne 7 : un lien entre r@this et rw2 ; ligne 8 : un lien entre r@parameter0 et rw3 ; ligne 9 : un lien entre rw3 et rx .

26 Dans notre implmentation, nous remplaons le @this par un nom de variable unique e c pour tout le programme ; nous identions le @this comme une variable locale dclarer e dans la mthode. Ce changement de nom de variable est ncessaire, sinon on aura le e e mme nom @this pour toutes les mthodes. e e Si on suppose que la variable w1 est de type T, alors nous allons crer aussi ces liens e pour toutes les classes qui hritent de T (ou implmente T dans le cas dune interface) e e et qui rednissent la mthode bar. Ces cas concernent le virtual invoke et le interface e e invoke. Les variables @this, @parameter0, et w3 sont uniques pour tous les appels de la mthode e bar. 4.2 Etat de la copie de la rfrence ` un point de programme ee a Nous exprimons les proprits dune rfrence comme suit : ee ee t ::= 0 | 1 e ::= 0 | 1 u ::= (e, t) o` : u t : dnit la proprit transitoire qui peut prendre la valeur 1 si la rfrence est e ee ee transitoire, sinon 0 ; e : dnit la proprit exclusive qui peut prendre la valeur 1 si la rfrence est e ee ee exclusive, sinon 0 ; u : dnit lunicit de la rfrence exprime avec le couple (e, t). e e ee e Si on consid`re laectation x = y, alors les valeurs admissibles des proprits exe ee clusive et transitoire (e, t) de la rfrence contenue dans la variable y dpendent de ses ee e proprits avant (eb , tb ) et apr`s (ea , ta ) ce point de programme. ee e si (e=0, t=0) alors (eb = ?, tb =0) et (ea =0, ta = ?) : si la rfrence est non-exclusive ee et non-transitoire ` un point du programme, alors la rfrence peut tre exclusive ou a ee e

27 non avant ce point du programme (le point dinterrogation est utilis pour exprimer e cette ambigit), mais ncessairement non-exclusive apr`s ce point du programme. u e e e Aussi elle est non-transitoire avant mais peut tre transitoire ou non apr`s ce point e e du programme parce que ce nest pas grave si elle devient transitoire. Toutefois, cela ne peut servir ` rien de la rendre transitoire (elle tait (0,0) dans le pass donc a e e elle ne peut pas participer ` une relation de composition de toute mani`re) ; a e si (e=0, t=1) alors (eb = ?, tb = ?) et (ea =0, ta =1) : si la rfrence est non-exclusive ee et transitoire ` un point de programme, alors elle peut prendre tous les cas avant a ce point de programme mais elle est non-exclusive et transitoire apr`s ce point de e programme ; si (e=1, t=0) alors (eb =1, tb =0) et (ea = ?, ta = ?) : si la rfrence est exclusive et ee non-transitoire ` un point de programme, alors la rfrence est exclusive et nona ee transitoire avant ce point de programme, mais on ne peut rien dduire sur les e valeurs de ses proprits apr`s ce point de programme. Seule la propagation des ee e contraintes, que nous allons dnir ci-dessous, peut nous conrmer si une rfrence e ee conserve son unicit ou pas. e Ces dirents cas peuvent tre dcomposer comme suit : e e e e=1 est un sous-type de e=0, donc on peut toujours remplacer un e=1 par un e=0 : on y perd de linformation mais le rsultat est valide ; e t=0 est un sous-type de t=1, donc on peut toujours remplacer un t=0 par un t=1 : on y perd de linformation mais le rsultat est valide ; e (1,t) se ddouble en (1,t) et (0,1) ; e (0,t) se ddouble en (0,t) et (0,t). e Le syst`me de contraintes a toujours au moins une solution, o` tous les e=0 : cest une e u solution triviale qui ne nous intresse pas vu quelle correspond ` un chec de notre e a e recherche de composition.

28 Pour lexemple :
1 2 3

x = y#1 ; z = y#2 ; w = x;

si y est unique ` la ligne 1, alors ` la ligne 2 nous avons deux cas possibles : a a si la rfrence de y (apr`s la ligne 1) doit tre unique, alors celle de x (ligne 1) doit ee e e tre temporaire, ce qui veut dire que nous allons imposer la mme contrainte sur e e la variable w (ligne 3), c.`.d. la rfrence de w doit tre aussi temporaire ; a ee e si la rfrence de x (ligne 1) doit tre unique, alors ncessairement la rfrence de y ee e e ee (ligne 1) est unique, mais y sera dsormais considre temporaire (apr`s la ligne 1), e ee e et donc nous allons imposer la mme contrainte sur la variable z (lignes 2), c.`.d. e a la rfrence de z doit tre aussi temporaire. ee e Pour conserver un historique du changement de lunicit de la rfrence, nous dnissons e ee e les variables logiques suivantes : 1. Nous dnissons les deux variables logiques (ery#1 , try#1 ) : e ery#1 : dnit la valeur de la proprit exclusive de la rfrence de la variable e ee ee y ` la ligne 1 ; a try#1 : dnit la valeur de la proprit transitoire de la rfrence dorigine de e ee ee la variable y ` la ligne 1. a 2. Nous dnissons les deux variables logiques (ery#2 , try#2 ) : e ery#2 : dnit la valeur de la proprit exclusive de la rfrence de la variable e ee ee y ` la ligne 2 ; a try#2 : dnit la valeur de la proprit transitoire de la rfrence de la variable e ee ee y ` la ligne 2. a 3. Nous dnissons les deux variables logiques (erx , trx ) : e erx : dnit la valeur de la proprit exclusive de la rfrence de la variable x e ee ee a ` la ligne 1 ;

29 trx : dnit la valeur de la proprit transitoire de la rfrence de la variable e ee ee x ` la ligne 1. a Nous pouvons donc distinguer les rfrences des direntes variables, mais aussi distinguer ee e la rfrence dune mme variable aux dirents points du programme. Cela nous permet ee e e de grer facilement le changement de lunicit des rfrences ; par exemple si la rfrence e e ee ee de y est unique ` la ligne 1 alors il est possible de la considrer autrement ` la ligne 2. a e a 4.3 Dnition des contraintes sur les variables logiques e Nous avons prsent dans la section prcdente les r`gles qui dterminent les valeurs e e e e e e des proprits de la rfrence contenue dans une variable aux dirents points du proee ee e gramme o` on lit la valeur de cette variable. Nous avons aussi dni des variables logiques u e qui caractrisent la rfrence en entre et les deux rfrences en sortie dune aectation. e ee e ee Nous dnissons dans cette section les contraintes sur les valeurs de ces variables logiques : e 1. Si (try#1 = 1) alors (trx = 1) et (try#2 = 1) : si une rfrence est transitoire, ee alors toutes les nouvelles rfrences cres ` partir de cette rfrence devront tre ee ee a ee e aussi transitoires. Cette contrainte est tr`s importante pour conserver lunicit de e e la rfrence en cas de transfert dunicit ; il devrait y avoir une seule rfrence ee e ee non-transitoire vers un objet pour pouvoir identier une relation de composition. a ee 2. Si (try#2 = 0) alors (try#1 = 0) : si, ` un point de programme, une rfrence est non-transitoire, alors, on peut conclure quelle est ncessairement non-transitoire e avant ce point de programme. 3. Si (ery#1 = 0) alors (erx = 0) et (ery#2 = 0) : si une rfrence est non-exclusive, ee alors toutes les nouvelles rfrences cres ` partir de cette rfrence devront tre ee ee a ee e non-exclusives. 4. Si (ery#1 = 1) alors (erx = 0) ou/et (ery#2 = 0) : si la rfrence dtenue par la ee e variable y ` la ligne 1 est exclusive alors soit que la rfrence de la variable y ` la a ee a ligne 2 devienne non-exclusive, soit que celle obtenue par la variable x, soit nonexclusive. Autrement dit, il est normal que lune des deux rfrences soit exclusive ee

30 ou que les deux soient non-exclusives, mais elles ne peuvent pas tre exclusives e toutes les deux. ee 5. Si (erx = 1) alors (ery#1 = 1) et (ery#2 = 0) et (try#2 = 1) : si la rfrence de la variable y doit tr exclusive, alors il est naturel que la rfrence de la variable y e ee (ligne 1) soit exclusive et que sa rfrence deviennent non-exclusive ` la ligne 2. ee a Cela permet le transfert dunict ` une autre rfrence, mais il faut que la rfrence ea ee ee de la variable y (ligne 2) soit transitoire. ee 6. Si (ery#2 = 1) alors (ery#1 = 1) et (erx = 0) et (trx = 1) : si la rfrence de la variable y (ligne 2) est exclusive, alors on peut conclure que celle de la variable y (ligne 1) est exclusive et celle de la variable x est non-exclusive ; naturellement, la rfrence de la variable x doit tre transitoire pour respecter la proprit dunicit. ee e ee e 4.4 Formalisation Notre algorithme de calcul de contraintes est en fait un algorithme qui essaie de trouver une drivation valide pour le programme dans le syst`me de r`gles suivant. e e e Dabord les r`gles de sous-typage qui permettent de perdre de linformation lorsque e ncessaire. Le jugement a la forme u u ce qui signie que si une variable a lunicit e e u, alors il est valide de la traiter comme ayant lunicit u : e (weak-e) (weak-t)

(1, t) (0, t) (re)

(e, 0) (e, 1)

uu

(e1 , t1 ) (e2 , t2 ) (e2 , t2 ) (e3 , t3 ) (trans) (e1 , t1 ) (e3 , t3 )

Les deux derni`res r`gles reprsentent la rexivit et la transitivit. e e e e e e

31 Ensuite, les r`gles de ddoublement. Le jugement a la forme u1 u u2 ce qui e e signie que u peut se ddoubler en u1 et u2 : e (split-e) (split-s)

(1, t) (1, t) (0, 1)

(0, t) (0, t) (0, t)

u1 u u2 (sym) u2 u u1 u1 u u2 u u u1 u1 u1 u u2 u2 u2 (weaken)

Ces r`gles de soustypage et de ddoublement garantissent que la proprit dexclusivit e e ee e ne peut pas tre copie (elle ne peut au mieux qutre perdue), et que la proprit dtre e e e ee e transitoire ` linverse ne peut pas tre perdue. a e Finalement, les r`gles pour chaque opration. Elles utilisent un environnement qui e e associe ` chaque variable son unicit, un autre environnement qui associe ` chaque a e a mthode et chaque champ son unicit, et elles ont la forme ; e e i ce qui

signie que linstruction i lorsquexcute dans un contexte et renvoie un nouveau e e contexte . uy u ux x = y , y : uy , x : ux

; , y : u

uy u (ef , 0) , f : (ef , 0); , y : u x.f = y , y : uy ux (ef , 0) (ef , 0) , f : (ef , 0); x = y.f , x : ux (1, 0) u x = new C , x : u uy uy us ur ux x = invoke y.m(z) , y : uy , z : uz , x : ux

uz uz ua , m : (us , ua ) ur ; , y : uy , z : uz

Lors des jonctions de ot de contrle, il faut bien sr unier les environnements de o u chaque branche entrante.

CHAPITRE 5

IMPLEMENTATION

5.1

Prsentation de notre implmentation e e La premi`re partie de limplmentation de notre approche concerne lanalyse du proe e

gramme et la construction dun graphe de dpendance entre les variables et les champs. e LAPI Shimple de Soot nous permet de traverser un programme et didentier les points du programme o` de nouvelles copies dune rfrence sont cres. La reprsentation u ee ee e Shimple nous garantit des points de dnition uniques pour chaque variable ; si une e variable est dnie deux fois dans le corps dune mthode, alors Shimple cre une noue e e velle variable pour sauvegarder la nouvelle valeur. Sil peut y avoir une ambigu e pour t distinguer les deux variables, alors des nuds Phi sont ajouts pour spcier quels sont e e les dirents points du programme qui ont redni la variable. e e Une particularit de notre analyse est de considrer ce mme comportement aussi en e e e cas de lecture de la valeur dune variable ; si on assigne la valeur dune variable en deux points de programmes dirents, alors notre syst`me va donner un nom unique ` chaque e e a variable en chaque point de programmes mais en assurant que les deux variables pointent sur la mme location en mmoire. Cela nous permet de mieux contrler lvolution de e e o e ltat de la rfrence pour chaque point de programme. Le rsultat de la traverse du e ee e e programme est une structure de donnes qui reprsente le graphe de dpendance entre e e e les variables et les champs du programme. La deuxi`me partie de notre analyse concerne la construction des contraintes sur e les nouvelles copies des rfrences. Chaque instruction de cration dune nouvelle copie ee e dun rfrence implique trois variables et champs ; pour chaque variable et champ, nous ee associons des variables logiques qui reprsentent ltat de la copie de la rfrence ` un e e ee a point de programme prcis. Nous utilisons un syst`me de rsolution de contraintes pour e e e vrier la persistance des contraintes tablies dans le programme. e e

33 5.2 Cadriciel Soot Nous nous basons dans notre implmentation sur le cadriciel Soot. Soot est un cadrie ciel doptimisation Java [VRCG+ 99]. Il permet de convertir le bytecode Java en quatre reprsentations intermdiaires possibles dont Shimple (une reprsentation intermdiaire e e e e type du programme ` 3-adresses). Nous considrons uniquement la reprsentation Shimple e a e e car elle ore une forme idale pour eectuer lanalyse du programme, en particulier, nous e signalons que : Shimple reprsente le programme en squence dinstructions ` trois adresses ; lanae e a lyse du programme devient plus facile vu quune instruction ` trois adresses vhicule, a e au plus, une opration [ALSU07] ; e Shimple ore une implmentation de SSA, cela nous garantit des points de dnitions e e distincts pour toutes les variables du programme et donc nous pouvons estimer que chaque variable dtient une copie de la rfrence unique et distincte dans tout le e ee programme. Il est important de signaler que Soot fournit plusieurs implmentations danalyse et e doptimisations du code. Nous nutilisons presque aucune de ces analyses et optimisations dans notre implmentation. Seul la reprsentation Shimple du code est utilise ; elle ore e e e une implmentation de SSA qui nous permet de construire notre analyse que nous avons e dtaille dans le chapitre prcdent. e e e e Nous prsentons, ci-dessous, les instructions importantes de la reprsentation Shimple [Lho02]. e e 5.2.1 Instruction de copie

Une instruction de copie (assignment statement) a la forme p = q ; nous considrons e dans notre analyse uniquement les types non-primitives. Apr`s lexcution de cette inse e truction, les variables p et q rfrencent le mme objet. ee e

34 5.2.2 Instruction didentit e

Linstruction didentit (identity statement) est une instruction de copie particuli`re. e e La source de la copie est une variable virtuelle (dnie par Shimple) qui reprsente un e e param`tre de mthode ou un param`tre dune exception. Par exemple dans notre analyse, e e e nous considrons les instructions p := @this : T ; (o` this est le param`tre implicite e u e qui pointe sur une instance de la classe T), et p := @parameter0 : java.lang.Object ; (o` parameter0 est le premier param`tre formel de la mthode de type java.lang.Object). u e e 5.2.3 Cration dobjet e

La cration dobjet (allocation statement) a la forme p = new T() ; elle permet ` la e a variable p de rfrencer un nouveau objet allou par cette instruction. Nous considrons ee e e dans notre analyse les instructions de cration dobjets simples et de tableaux. Lappel e du constructeur associ ` cette instruction dallocation est gre dans une instruction e a ee dinvocation spare. e e 5.2.4 Ecriture dans un champ

Lcriture dans un champ (eld store) a la forme p.f = q ; o` f reprsente un champ. e u e Cette instruction sauvegarde la valeur de la variable q dans le champ f de lobjet point e par la variable p. 5.2.5 Lecture dun champ

La lecture dun champ (eld load ) a la forme p = q.f ; elle permet de charger la valeur du champ f de lobjet point par la variable q et de la sauvegarder dans la variable e p. 5.2.6 Ecriture dans un champ statique

Lcriture dans un champ statique (static eld store) a la forme T.f = p ; elle saue vegarde la valeur de la variable p dans le champ statique f dni dans la classe dont le e

35 type est T. Un champ statique dans une classe est instanci une seule fois pour toutes les e instances de cette classe. 5.2.7 Lecture dun champ statique

La lecture dun champ statique (static eld load ) a la forme p = T.f ; elle charge la valeur du champ statique f et la sauvegarde dans la variable p. 5.2.8 Ecriture dans le tableau

Lcriture dans un tableau (array store) a la forme p[i] = q ; elle sauvegarde la e valeur de la variable q dans li`me lment du tableau point par la variable p. e ee e 5.2.9 Lecture dun lment du tableau ee

La lecture dun lment du tableau (array load ) a la forme p = q[i] ; elle charge ee la valeur du i`me lment du tableau point par la variable q et la sauvegarde dans la e ee e variable p. 5.2.10 Instruction de coercition

Linstruction de coercition de type (typecast statement) a la forme p = (T) q ; elle permet daecter la valeur de la variable q ` la variable p. La machine virtuelle Java a vrie que le type de la variable q est un sous type de T ; si ce nest pas le cas, une e exception est leve. e 5.2.11 Appel de mthode e

Lappel de mthode (invocation statement) permet dinvoquer une mthode. Si la e e mthode dnit des param`tres, cette instruction contiendra les variables qui seront e e e passes en param`tres. Si la mthode retourne une valeur, cette instruction peut contenir e e e une variable qui recevra la valeur retourne. Soot supporte quatre types dinvocation e specialinvoke, staticinvoke, virtualinvoke et interfceinvoke.

36 5.2.12 Retour de mthode e

Le retour de mthode (return statement) a la forme de return ou return p ; elle e permet de retourner du contexte de la mthode courante au contexte de la mthode qui e e excute linstruction de linvocation de la mthode courante. En cas de prsence dune e e e valeur de retour, elle peut aecter cette valeur ` une variable associe ` linstruction de a e a linvocation de la mthode courante. e 5.2.13 Instruction Phi

Cette instruction est une particularit de la reprsentation Shimple ; elle a la forme p e e = Phi(q0 (0), q1 (1)). Ce qui veut dire que la variable p peut, en fonction du ot de contrle, avoir la valeur de la variable q0 dnit au point de programme 0 ou la valeur o e de la variable q1 dnie au point de programme 1. e 5.3 Cadriciel Choco Nous avons choisi dutiliser Choco pour la rsolution des contraintes que nous avons e dnies sur les proprits des rfrences. Choco est un cadriciel ` code source ouvert en e ee ee a Java (accessible ` partir du site Web sourceforge.net) qui dnit une couche abstraite pour a e construire et rsoudre des probl`mes de contraintes. Llment central dun programme e e ee Choco est lobjet Problem qui permet de dnir des variables, leurs domaines et des e contraintes sur ces variables. Choco fournit aussi diverses interfaces pour ajouter de nouvelles contraintes avec des algorithmes de propagation personnaliss. e 5.3.1 Probl`mes e

Typiquement la cration dun probl`me est faite en crant une instance de la classe e e e Problem :
1

AbstractProblem pb = new Problem();

37 5.3.2 Variables et domaines

La cration des variables est faite par des mthodes accessibles ` partir de linstance e e a de la classe Problem. LAPI Choco supporte plusieurs types de variables ; chaque type (par exemple IntDomainVar) fournit des mthodes spciques pour grer le domaine e e e associ ` une variable. ea
1

IntDomainVar v1 = pb.makeEnumIntVar(var1, 1, 3);

o` v1 est une variable numr dont le nom est var1 et le domaine est lensemble [1, 3]. u e ee Dans notre implmentation les variables correspondent aux variables logiques (exclue sive et transient) que nous associons aux rfrences. Par exemple, pour le code suivant, ee nous crons les variables logiques ery#1 , try#1 , ery#2 , try#2 , erx , et trx . e
1 2

x = y; z = y; Le domaine que nous associons ` chaque variable logique est [0, 1]. Malheureusement a

avec 6 variables logiques, la rsolution des contraintes devient extrmement longue. Cest e e pourquoi nous avons choisit de rduire ce nombre de variables ` 3 ; par exemple, les deux e a varaibles logiques erx , et trx associes ` la rfrence de la variable x ` la ligne 1 seront e a ee a remplaces par la variable logique urx dont le domaine est initialis comme suit : e e si erx = 0 et trx = 0 alors urx = 0 ; si erx = 0 et trx = 1 alors urx = 1 ; si erx = 1 et trx = 0 alors urx = 2. Le code pour crer de nouvelles variables en utilisant lAPI Choco est comme suit : e
1

IntDomainVar ux = pb.makeEnumIntVar(ux, 0, 2); Le domaine de la variable prsente ci-dessous correspond au cas gnrique o` nous e e e u

navons aucune information sur les valeurs que peut prendre les proprits de la rfrence. ee ee Cependant il est possible doptimiser encore le domaine de la variable si nous connaissons une partie ou toute linformation sur ces valeurs. Le code suivant montre les dirents e cas o` nous crons des domaines dirents en fonction des valeurs des proprits de la u e e ee rfrence : ee

38
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

//the parameter e is true if exclusive , false if not exclusive , otherwise null //the parameter t is true if transient , false if not transient , otherwise null public IntDomainVar getIntDomainVar(Problem pb, String variableName, Boolean e, // Boolean t) { if (e == null) { if (t == null) { // can be normal, transient or unique return pb.makeEnumIntVar((variableName + (0,1,2)), 0, 2); } else if (t == false) { // can be normal or unique return pb.makeEnumIntVar((variableName + (0,2)), new int[]{0, 2}); } } else if (e == true) { if (t == false) { // can be just unique return pb.makeEnumIntVar((variableName + (2)), 2, 2); } } else if (e == false) { if (t == true) { // can be just transient return pb.makeEnumIntVar((variableName + (1)), 1, 1); } } return null ; }

5.3.3

Contraintes

` A partir de linstance de Problem, il est possible de crer des contraintes (arithmtique, e e logiques ou prnies) sur les domaines des variables. e
1 2 3 4

IntDomainVar v1 = pb.makeEnumIntVar(var1, 1, 10); IntDomainVar v2 = pb.makeEnumIntVar(var2, 5, 20); Constraint c1 = pb.neq(v1, v2); pb.post(c1);

o` c1 correspond ` la contrainte de dirence entre les variables v1 et v2. Cette contrainte u a e sera accessible au probl`me en utilisant la mthode post. Le code suivant prsente une e e e vue, simplie, des contraintes cres dans notre implmentation : e ee e

39
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

//if we have statement : x = y; //the parameter yiu specify the uniqueness property value of y at this statement //the parameter xu specify the uniqueness property value of x at this statement //the parameter you specify the uniqueness property value of y after this statement public void getConstraintsB(Problem pb, IntDomainVar yiu, IntDomainVar xu, IntDomainVar you) { //when yiu is normal then xu and you cant be unique Constraint constraintA = pb.and( pb.eq(yiu, 0), pb.neq(xu, 2), pb.neq(you, 2)); //when yiu is transient then xu and you are also transient Constraint constraintB = pb.and( pb.eq(yiu, 1), pb.eq(xu, 1), pb.eq(you, 1)); //when yiu is unique and xu is normal then you cant be unique Constraint constraintC = pb.and( pb.eq(yiu, 2), pb.eq(xu, 0), pb.neq(you, 2)); //when yiu is unique and xu is transient then you is free to take all the values Constraint constraintD = pb.and( pb.eq(yiu, 2), pb.eq(xu, 1), pb.or(pb.eq(you, 0), pb.eq(you, 1), pb.eq(you, 2))); //when yiu is unique and xu is uniqe then you must be transient Constraint constraintE = pb.and( pb.eq(yiu, 2), pb.eq(xu, 2), pb.eq(you, 1)); Constraint[] allConstraints = new Constraint[]{constraintA, constraintB, constraintC, constraintD, constraintE}; pb.post(pb.or(allConstraints )); }

40 5.3.4 Rsolution e

Rsoudre un probl`me consiste ` trouver la ou les solutions qui correspondent aux e e a contraintes dnies sur les domaines des variables du probl`me en question. Typiquement, e e cela est fait en utilisant la mthode solve de la classe Problem : e
1 2 3 4 5 6 7

if (pb.solve ()) { do { for ( int i = 0; i < pb.getNbIntVars(); i ++) { print(pb.getIntVar(i) + : + ((IntDomainVar) pb.getIntVar(i)).getVal()); } } while(pb.nextSolution()); } LAPI Choco fournit des outils pour optimiser la recherche en utilisant les mthodes e

minimize et maximize, aussi limiter lespace de recherche, ou mme dnir son propre e e algorithme de propagation de la recherche. 5.4 Un exemple pour illustrer le fonctionnement de notre implmentation e Dans lexemple suivant, nous prsentons la reprsentation Shimple du programme e e qui sera utilise pour construire notre graphe de dpendance entre les variables et les e e champs. Lexemple contient la classe principale CompositionExample1 qui contient la mthode main et aussi deux classes A et B (nous considrons uniquement les programmes e e complets).
1 2 3 4 5 6 7 8 9 10 11 12 13

package thesisExample1; class CompositionExample1 { public static void main(String[] args) { A a1 = new A(); } } class A { private B b1 = new B(); } class B {}

41 Analyse du programme : LAPI Soot nous permet de faire une traverse du proe

gramme ; chaque mthode a un corps compos de plusieurs units. Chaque unit correse e e e pond ` une instruction du programme. Le pseudo programme suivant correspond ` la a a reprsentation Shimple de notre exemple. e
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

class thesisExample1.CompositionExample1 extends java.lang.Object { void <init>() { thesisExample1.CompositionExample1 r0; r0 := @this: thesisExample1.CompositionExample1; specialinvoke r0.<java.lang.Object: void <init>()>(); return; } public static void main(java.lang.String []) { java .lang.String [] r0; thesisExample1.A $r1, a1; r0 := @parameter0: java.lang.String []; $r1 = new thesisExample1.A; specialinvoke $r1.<thesisExample1.A: void <init>()>(); a1 = $r1; return; } } class thesisExample1.A extends java.lang.Object { private thesisExample1.B b1; void <init>() { thesisExample1.A r0; thesisExample1.B $r1; r0 := @this: thesisExample1.A; specialinvoke r0.<java.lang.Object: void <init>()>(); $r1 = new thesisExample1.B; specialinvoke $r1.<thesisExample1.B: void <init>()>(); r0.<thesisExample1.A: thesisExample1.B b1> = $r1; return; } } Lanalyse du programme et la construction du graphe de dpendance entre les vae

1 2 3 4 5 6 7 8 9 10 11 12 13 14

riables et champs du programme commence par la mthode dentre principale du proe e gramme (Soot ore la possibilit de spcier la classe principale du programme qui e e contient la mthode main). Par la suite, lappel de mthode constitue un point dentre e e e a ` un autre contexte qui sera analys ` son tour. ea

42 Dans notre exemple, lanalyse de la mthode main de la classe CompositionExample1 e donne les dpendances suivantes : e
1 2

<r0 java.lang.String[]> : 14db0e3 [1982fc1] <@parameter0 java.lang.String[]> : 676437 [1e4853f] <$r1 thesisExample1.A> : 110c31 [1e808ca] <new thesisExample1.A thesisExample1.A> : 992bae [2bd3a] <@this thesisExample1.A> : 1d53f5b [1329642] <$r1 thesisExample1.A> : 110c31 [1e808ca] <$r1 thesisExample1.A> : 110c31 [26d607] <a1 thesisExample1.A> : fefe3f [1ad98ef] <$r1 thesisExample1.A> : 110c31 [26d607] Pour chaque variable, nous associons deux codes qui les distinguent dans le pro-

1 2

1 2 3

1 2

gramme. Typiquement, Soot nous garantit cette unicit pour tous les points du proe gramme o` une variable est dnit . Mais, nous avons besoin de garantir lunicit aussi u e e pour tous les points du programme o` on lit la valeur dune variable. Ainsi, chaque u variable a deux codes, le premier le distingue dans le programme (correspond ` sa a dnition), le deuxi`me code distingue son utilisation. Nous prsentons une description e e e des dpendances cites ci-dessus : e e le premier lien associe le param`tre formel de la mthode main @parameter0 avec e e la variable r0 dnie par Soot ; e le deuxi`me lien associe la variable new (que nous avons cr pour reprsenter e ee e lopration dinstanciation) avec la variable $r1 dnie par Soot. La variable new e e est unique dans le programme ; le troisi`me lien concerne lappel du constructeur par dfaut de la classe A. Soot e e spare linstanciation et lappel du constructeur en deux instructions distinctes. e Le param`tre implicite qui reprsente le this est utilis dans la mthode init de la e e e e classe A. Puisque la variable $r1 sera utilise plus tard dans le programme (elle sera e aecte ` la variable a1), nous lui donnons des codes dirents pour lidentier e a e dans les deux points de programme ;

43 le quatri`me lien associe la variable $r1 avec la vraiable a1 dnie dans la mthode e e e main. Lanalyse de la mthode init de la classe A donne les dpendances suivantes : e e
1 2

<r0 thesisExample1.A> : 138c63 [165f738] <@this thesisExample1.A> : 1d53f5b [1329642] <$r1 thesisExample1.B> : c2b2f6 [149b290] <new thesisExample1.B thesisExample1.B> : 16a38b5 [b1074a] <@this thesisExample1.B> : 55a338 [4ee70b] <$r1 thesisExample1.B> : c2b2f6 [149b290] <$r1 thesisExample1.B> : c2b2f6 [22ab57] <b1 thesisExample1.B> : 1eec35 [25c828] <$r1 thesisExample1.B> : c2b2f6 [22ab57] <r0 thesisExample1.B> : 77ef83 [d85cc] <@this thesisExample1.B> : 55a338 [4ee70b] Les deux codes que nous associons ` chaque variable identient la copie de la rfrence a ee

1 2

1 2 3

1 2

1 2

que contient cette variable. Cette copie de la rfrence est unique pour tout le programme. ee Cela nous permet dtablir des contraintes sur chaque copie de la rfrence. La rsolution e ee e de ces contraintes nous donne les solutions possibles pour chaque copie de la rfrence ; ee si une solution pour une copie de la rfrence arme quelle est unique alors le syst`me ee e identie une relation de composition pour la classe qui dclare le champ qui dtient cette e e copie de la rfrence. ee Dnition des contraintes : notre implmentation produit plusieurs rsultats dont e e e chacune exprime un contexte de la propagation des contraintes dans le programme. Nous tudions le cas o` la relation de composition est conrme. Nous avons prsent les e u e e e rsultats de lanalyse du programme ; la construction du graphe de dpendance des copies e e de la rfrence. Pour des raisons de lisibilit, nous prsentons uniquement les dpendances ee e e e qui concernent le champ b1 :
1 2 3

<$r1 thesisExample1.B> : c2b2f6 [149b290] : (0, 1, 2):2 <new thesisExample1.B thesisExample1.B> : 16a38b5 [b1074a] : (2):2 <new thesisExample1.B thesisExample1.B> : 16a38b5 [e63ab8] : (1):1

44
1 2 3

<@this thesisExample1.B> : 55a338 [4ee70b] : (0, 1, 2):1 <$r1 thesisExample1.B> : c2b2f6 [149b290] : (0, 1, 2):2 <$r1 thesisExample1.B> : c2b2f6 [22ab57] : (0, 1, 2):2 <r0 thesisExample1.B> : 77ef83 [d85cc] : (0, 1, 2):1 <@this thesisExample1.B> : 55a338 [4ee70b] : (0, 1, 2):1 <@this thesisExample1.B> : 55a338 [ac2b57] : (0, 1, 2):1 <b1 thesisExample1.B> : 1eec35 [25c828] : (0, 2):2 <$r1 thesisExample1.B> : c2b2f6 [22ab57] : (0, 1, 2):2 <$r1 thesisExample1.B> : c2b2f6 [34ec2e] : (0, 1, 2):1

1 2 3

1 2 3

Une copie de la rfrence peut avoir trois tats possibles (0 : normale, 1 : temporaire, 2 : ee e unique). La rsolution des contraintes nous donne les tats pour lesquelles il ny a pas de e e conit avec notre syst`me de contrainte. e premi`re dpendance : loperateur dinstanciation new() dtient une copie de la e e e rfrence qui est considre unique. Nous imposons que cette copie de la rfrence ee ee ee soit temporaire dans le reste du programme. Ce qui nous autorise ` propager cette a unicit dans le programme ; e deuxi`me dpendance : le passage implicite de la variable this comme param`tre au e e e constructeur de la classe B, ne change pas ltat de la rfrence qui reste unique. Nae ee turellement, cela est vrai parce que la variable this dtient une copie de la rfrence e ee qui est consid`re temporaire et que le autres contraintes ne causent pas de conit ee avec cet tat ; e troisi`me dpendance : puisque la copie de la rfrence dans la variable this est e e ee temporaire alors celle de la variable r0 doit tre aussi temporaire. Ce qui est valide e et donc pas de conit ; quatri`me dpendance : puisquil ny a pas dautres dpendances, notre syst`me de e e e e contraintes autorise le transfert dunicit au champ b1. e Vu que la copie de la rfrence dans le champ b1 peut tre unique, notre syst`me identie ee e e une relation de composition entre la classe A et la classe B.

CHAPITRE 6

VALIDATION ET LIMITATIONS

6.1

Validation La validation de notre implmentation est faite en deux parties. La premi`re partie e e

de lexprimentation concerne le test doprationnalit de notre approche. Nous avons e e e appliqu notre syst`me sur les exemples que nous avons introduits dans le chapitre 3. Les e e rsultats correspondaient parfaitement ` nos prvisions et sajustaient avec nos choix de e a e modlisation et dimplmentation de la relation de composition. La deuxi`me partie de e e e lexprimentation concerne lapplication de notre syst`me sur un jeu de test de rfrence ; e e ee le but est de vrier la cohrence des rsultats sur de grands programmes et dvaluer les e e e e performances et les limitations de notre syst`me. e Nous avons prsent dans le chapitre 3 quatre exemples. Nous tudions ci-dessous les e e e rsultats obtenus en y appliquant notre syst`me. e e Application de notre implmentation sur lexemple 1, 2, 3 et 4 : notre implmentation e e identie les relations de composition dans lexemple 1, 2 et choue ` identier ces relations e a dans les exemples 3 et 4. les exemples 1 et 2 reprsentent les cas o` ils existent uniquement des rfrences e u ee temporaires avec une seule rfrence unique ; ee lexemple 3 reprsente le cas o` il existe plus dune rfrence non-temporaire sur e u ee un objet ; lexemple 4 reprsente le cas o` une partie est rfrence par une autre partie du e u ee e mme tout. Notre implmentation choue ` grer ce genre de cas. e e e a e Cas o` un champ de A est de type liste dlments de type B : u ee ce cas peut

tre implment avec Java en utilisant un tableau, un conteneur (i.e., Vector) ou une e e e liste chaine (o` chaque instance poss`de une rfrence vers une autre instance). Nous e u e ee

46 tudions le cas du conteneur en utilisant un exemple similaire ` celui fourni dans larticle e a de Milanova [Mil05] :
1 2 3

class X { public void m() {} } class MilanovaCompositionExample extends Object { public static void main(String[] args) { Vector v = new Vector(5); X x = new X(); v.addElement(x, 0); VIterator e = v.elements(); x = (X) e.nextElement(); x.m(); } } class Vector extends Object { protected Object[] data; public int count; public Vector(int size ) { data = new Object[size]; count = 0; } public void addElement(Object e, int at) { data[at] = e; count++; } public Object elementAt(int at) { return data[at ]; } public VIterator elements() { return new VIterator(this ); } } nal class VIterator extends Object { Vector vector; int count; public VIterator(Vector v) { vector = v;

1 2 3 4 5 6 7 8 9 10

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

1 2 3 4 5 6

47
7 8 9 10 11 12 13 14 15 16 17 18 19 20

count = 0; } public Object nextElement() { Object[] data = vector.data; int i = this .count; this .count++; return data[i ]; } public boolean hasMoreElements() { return (vector = null && vector.data =null && count < vector.count); } } Nous nous focalisons sur les rfrences du champ data de la classe Vector et du champ ee

vector de la classe VIterator. Nous faisons une distinction entre lobjet tableau rfrenc par le champ data et les ee e objets qui sont lments du tableau rfrencs par une variable virtuelle data[0] ; nous ee ee e rappelons que les assignations et les lectures des lments du tableau sont remplaces par ee e des assignations et des lectures du premier lment du tableau. ee Notre implmentation identie une relation de composition pour les champs data, e data[0] et vector. Comme nous lavons mentionn dans direntes sections des chapitres prcdents, e e e e nous nous intressons uniquement aux utilisations des rfrences ; cela explique les rsultats e ee e obtenus. Nous norons pas dans notre implmentation une solution directe pour grer les e e cas o` un champ de A est de type liste dlments de type B, ainsi notre implmentation u ee e ne permet pas dinfrer une relation de composition entre un conteneur et ses compoe sants : elle pourrait infrer quil y a une relation de composition entre A et le conteneur, e mais probablement pas entre le conteneur et B, et encore moins entre A et B. Application de notre implmentation sur la biblioth`que Zip du SDK Java e e (version 1.6 update 6) et JUnit (version 3.8.1) : Nous avons choisi dutiliser la mthode main fournie dans larticle de Milanova [Mil05] pour excuter notre test sur la e e biblioth`que Zip : e

48
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

class Main { public static void main(String[] args) { ZipEntry ph ZE; ZipInputStream ph ZIS; ZipOutputStream ph ZOS; ph ph ph ph ZE = new ZipEntry(); ZIS = new ZipInputStream(null); ZOS = new ZipOutputStream(null); ZE.setCrc(0);

try { ph ZE = ph ZIS.getNextEntry(); ph ZOS.putNextEntry(ph ZE); ph ZOS.closeEntry(); ph ZOS.nish(); } catch (Exception e) { e.printStackTrace(); } } } Le but principal de ces exprimentations est de valider loprationnalit de notre e e e

implmentation sur de vrais programmes. La partie analyse produit des rsultats core e rectes. Les performances dexcutions sont bonnes, cela prend globalement moins de 60 e seconds pour faire une analyse compl`te du programme. La deuxi`me partie qui concerne e e la rsolution des contraintes a cependant quelques limites de performance. Le temps de e rsolution des contraintes est long mais nous estimons que ce temps peut tre rduit e e e signicativement en implmentant un algorithme adapt ` nos contraintes ; la rsolution e ea e des contraintes ne doit pas ncessairement vrier tous les cas possibles, il est possible e e de limiter le champ de recherche des solutions et cela peut aider ` diminuer le temps a de calcul. Concernant lexactitude des rsultats, il ny a pas de grande dirence par e e rapport aux rsultats obtenus pour les exemples de tests ; la limite principale de notre e implmentation est lie au fait que nous considrons toutes les rfrences des champs e e e ee comme non-temporaires.

49 6.2 Limitations Les liens que nous avons crs dans la section prcdente nous permettent de construire ee e e des contraintes sur les proprits des rfrences dans un programme ; la rsolution de ces ee ee e contraintes nous donne les direntes solutions que peut avoir une rfrence. Un point tr`s e ee e important ` considrer dans la rsolution des contraintes est laspect temporaire dune a e e rfrence. Nous avons choisi de considrer les champs comme tant non-transitoires. ee e e Cette restriction nous empche de considrer une rfrence dun champ comme tant e e ee e temporaire ; par consquent, notre syst`me va chouer ` identier une relation de come e e a position si deux champs pointent sur le mme objet. Ce choix est tout ` fait correct en e a gnral, nanmoins il a quelques limitations ; ` savoir quon ne peut pas identier le cas e e e a o` une partie est rfrence par des objets qui sont eux mmes parties du tout. Dans u ee e e lexemple 4 du chapitre 3, on peut remarquer facilement que A est en relation de composition avec C, donc A est aussi en relation de composition avec B, mais notre syst`me e va identier uniquement une relation de composition entre A et C et va chouer ` infrer e a e une relation de composition entre A et B car linstance de B est rfre aussi dans C. eee Il y a plusieurs approches pour rsoudre ce probl`me, par exemple Milanova [Mil05] e e se base sur la notion de dominance dun nud sur dautres nuds dans un graphe pour dnir une fronti`re dacc`s a un objet (cela permet dignorer les appels ` lintrieur de e e e ` a e cette fronti`re), aussi elle utilise une technique de simplication du graphe en supprimant e tous les sous graphes issus dune cration ou utilisation temporaire dune variable. Une e extension possible de notre approche serait de pouvoir accepter la rfrence dun champ ee comme transitoire si les rfrences vers son objet parent sont toutes transitoires. ee 6.3 Solutions conservatrices pour lanalyse des cas particuliers LAPI Soot nous donne une grande exibilit ` analyser le programme et ore direntes ea e fonctions pour manipuler les dirents lments du programme (classes, mthodes, champs, e ee e variables et instructions). Cependant, nous avons choisi de considrer des approches e conservatrices pour grer certains cas particuliers comme les tableaux et la porte dynae e mique.

50 Tableaux : nous avons considr un tableau comme un simple objet ; les instructions ee

de lecture et dcriture dans un lment dun tableau sont traites respectivement comme e ee e une lecture et criture dans la variable ou le champ qui correspond ` la dclaration du e a e tableau. Porte Dynamique : la porte dune dclaration est dtermine seulement ` lexcution e e e e e a e du programme. Par exemple, avec :
1 2 3

void main(X r) { r .bar(); }

il est dicile de savoir statiquement quelle mthode sera invoque. Si on consid`re que Y e e e est une sous-classe de X et que Y rednit la mthode bar alors on ne conna e e tra le type de la rfrence de la variable r seulement ` lexcution. ee a e Dans notre analyse, nous considrons la dnition de la mthode dans le type courant e e e (sil sagit dune classe) ainsi que toutes les rednitions de cette mthode dans les sous e e types du type courant (ou les implmentations de la mthode au cas dune interface). e e Chargement dynamique : ce cas est tr`s compliqu ` grer ; en fait, le type est connu e ea e

a ` lexcution du programme. Il peut sagir dune classe du programme, ou peut-tre e e importe dun autre module ou biblioth`que. Par exemple, lutilisation de la mthode e e e java.lang.Class.forName(java.lang.String), le param`tre de cette mthode peut e e re inconnu ` la compilation, donc il serait impossible de rsoudre statiquement un appel e a e de mthode. Une possible mani`re de grer ce probl`me est de vrier si le type est e e e e e spci explicitement sous forme de cha de caract`res dans le programme ou parfois e e ne e exploiter les instructions de coercition de type pour donner une approximation du type dobjets crs dynamiquement [ALSU07]. ee

CHAPITRE 7

CONCLUSION ET PERSPECTIVES

Ce m`moire prsente une nouvelle approche pour identier statiquement la relation de e e composition dans le code source. Nous avons propos une dnition de la relation de come e position qui permet de lappliquer directement dans le langage de programmation Java sous forme dannotations. Ainsi, notre approche permet aux dirents intervenants dans e la mise en uvre dun programme dintervenir pour annoter les champs du programme o` on esp`re conserver lunicit des rfrences vers des parties ; ces champs seront annots u e e ee e comme uniques. Aussi, la possibilit dannoter les autres champs comme temporaires. e Nous avons implment un syst`me pour prouver la validit de notre concept. Nous e e e e avons utilis Soot qui nous a permis davoir une grande exibilit dans lanalyse du code. e e Notre syst`me a t test sur des programmes complets et les rsultats obtenus correse ee e e pondaient bien ` ceux attendus. Un apport principal de notre syst`me est sa capacit a e e a ` donner une explication pour chaque solution. Ceci est bas principalement sur notre e dnition de la relation de composition et aussi sur les contraintes que nous avons tablies e e sur lutilisation des rfrences. Ainsi, une personne qui eectue lanalyse du programme ee pourra savoir pourquoi un champ a t identi comme lment dun tout et donc coree e ee respond ` une relation de composition et aussi savoir pourquoi le syst`me a chou ` a e e e a identier une relation de composition pour un champ donn. Cette information peut tre e e utile et importante pour faire des ajustements dans le programme pour mieux annoter les champs du programme. Par exemple, un champ dont la dure de vie est temporaire e pourra tre annot comme transitoire et donc aider le syst`me ` identier une relation e e e a de composition. Notre travail futur consistera ` autoriser des champs pour quils soient temporaires a (principalement le cas o` une partie dun tout rfrence une autre partie du mme u ee e tout), grer le cas des conteneurs et faire dautres tests sur des benchmarks pour mieux e exprimenter et valider notre approche. e

BIBLIOGRAPHIE

[ALSU07]

A. Aho, M. Lam, R. Sethi, and J. Ullman. Compilateurs : principes, techniques et outils - 2e dition. Pearson Education, 2007. e

[And94]

L. O. Andersen. Program Analysis and Specialization for the C Programming Language. Phd thesis, University of Copenhagen, 1994.

[BHSPLB03] F. Barbier, B. Henderson-Sellers, A.L. Parc-Lacayrelle, and J.-M. Bruel. Formalization of the whole-part relationship in the unied modeling language. IEEE Transactions on Software Engineering, 29(5) :459470, 2003. [BRJ98] G. Booch, J. Rumbaugh, and I. Jacobson. The Unied Modeling Language User Guide. Addison-Wesley, 1998. [CFR+ 91] R. Cytron, J. Ferrante, B. K. Rosen, M. N. Wegman, and F. K. Zadeck. Eciently computing static single assignment form and the control dependence graph. Brown University, 1991. [CR07] S. Cherem and R. Rugina. Uniqueness inference for compile-time object deallocation. Proceedings of the 6th international symposium on Memory management, pages 117128, 2007. [EGH94] M. Emami, R. Ghiya, and L. J. Hendren. Context-sensitive interprocedural points-to analysis in the presence of function pointers. Proceedings of the ACM SIGPLAN 1994 conference on Programming language design and implementation, pages 242256, 1994. [Ern03] M. D. Ernst. Static and dynamic analysis : synergy and duality. In Proceedings of the ICSE Workshop on Dynamic Analysis, pages 2427, 2003. [GAA04] Y.-G. Guhneuc and H. Albin-Amiot. Recovering binary class relatione e ships : Putting icing on the uml cake. Proceedings of the 19th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, 2004.

53 [GCGZ06] J. Gensel, C. Capponi, P. Genoud, and D. Zibelin. Vers une intgration e e des relations partie-tout en arom. In Langage et Mod`les a Objets, pages e ` 5370, 2006. [Gro07] Object Management Group. v2.1.2. 2007. [JR00] D. Jackson and M. Rinard. Software analysis : a roadmap. Proceedings of the Conference on The Future of Software Engineering, pages 133145, 2000. [KG01] R. Kollmann and M. Gogolla. Application of uml associations and their adornments in design recovery. Proceedings of the Eighth Working Conference on Reverse Engineering, pages 8191, 2001. [Kil99] H. Kilov. Business Specications : The Key to Successful Software Engineering, 1st edition. Prentice Hall, 1999. [Lho02] O. Lhotk. A exible points-to analysis framework for java. Masters thesis, a McGill University, 2002. [MF07] K.-K. Ma and J. S. Foster. Inferring aliasing and encapsulation properties for java. Proceedings of the 22nd annual ACM SIGPLAN conference on Object oriented programming systems and applications, pages 423440, 2007. [Mil05] A. Milanova. Precise identication of composition relationships for uml class diagrams. Proceedings of the 20th IEEE/ACM international Conference on Automated software engineering, pages 7685, 2005. [Muc97] S. Muchnick. Advanced Compiler Design and Implementation. Morgan Kaufmann, 1997. [Mul97] P.-A. Muller. Modlisation objet avec UML. Eyrolles, 1997. e Unied modeling language specication,

54 [VRCG+ 99] R. Valle-Rai, P. Co, E. Gagnon, L. Hendren, P. Lam, and V. Sundaresan. e Soot - a java bytecode optimization framework. Proceedings of the 1999 conference of the Centre for Advanced Studies on Collaborative research, page 13, 1999. [WCH87] M. Winston, R. Chan, and D. Herrmann. A taxonomy of part-whole relations. Cognitive Science, 11 :417444, 1987. [YSC+ 05] D. Yeh, P.-C. Sun, W. Chu, C.-L. Lin, and H. Yang. An empirical study of a reverse engineering method for aggregation relationship based on operation propagation. Proceedings of the 29th Annual International Computer Software and Applications Conference, 1 :95100, 2005.