APPLICATION DES TECHNIQUES DE FOCALISATION POUR LA COMPRÉHENSION DE PROGRAMMES

EMNA MENIF

APPLICATION DES TECHNIQUES DE

FOCALISATION POUR LA COMPRÉHENSION DE PROGRAMMES

Mémoire présenté

à la FacuIté des études supérieures de l'Université La~ral

pour I'obtent ion

du grade de Maître ès Sciences (hi.Sc.)

Département d'Informat ique

FACKLTE DES SCTEKCES ET DE GÉSIE UYIVERSITÉ LAVAL

Novembre 1998

@ Emna Menif, 1998

National Library Bibliothèque nationale du Canada

Acquisitions and Acquisitions et

Bibliographie Services services bibliographiques

395 Wellington Street 395. rue Wellington OttawaON K l A O N 4 CMawaON K1AON4

Canada Canada

Yaur file Varre refërenc8

Our Ne Notre réUrence

The author has granted a non- L'auteur a accordé une licence non exclusive licence allowing the exclusive permettant

à

la

National L~hrary of Canada

to

Bibliothèque nationale du Canada de reproduce, loan, distribute or sell reproduire, prêter, distribuer ou

copies of this thesis in microfom, vendre des copies de cette thèse sous paper or electronic formats. la forme de ~ILicrofiche/fiIm, de

reproduction sur papier ou sur format électronique.

The author retains ownership of the L'auteur conserve la propriété du copyright in this thesis. Neither the droit d'auteur qui protège cette thèse.

thesis nor substantial extracts fkom it Ni la thèse

ni

des extraits substantiels rnay be printed or otherwise de celle-ci ne doivent être imprimés reproduced without the author's ou autrement reproduits sans son

permission. autorisation.

Dédicace

A

mes parents: pour tous les sacrifices quïls ont consenti pour m o n iducation et mes itudes. Qu'ils trouvent dans ce traoail ^Ze témoignage de mon a m o u r et ma gra fitude.

mes frères! ma soeur et mes neoeuz, arec toute mon affection e t t o u s m e s voeux de rEussite et de bonheur.

-4 _tous mes arni(r).s et à tous ^{C E U X} que j a i m é .

Remerciements

J e tiens à remercier mon directeur de recherche, M. Mourad Debbabi, Professeur au département d'hformati que de l'Université Laval, pour m'avoir fait l'honneur de superviser ma maîtrise. Ses compétences, ses conseils me furent très précieux tout au long de ce travail.

Toute ma gratitude et mes remerciements à mon codirecteur, M. Hakim Lounis?

chercheur au Centre de Recherche Informatique de Montréal et Professeur associé au département d'Informatique de l'Université Laval' pour avoir dirigé ^{m o n} projet de recherche. Ses conseils. ses qualités humaines, ainsi que sa disponibilité n'ont jamais fait défaut tout a u long de notre collaboration.

Mes remerciements s'adressent. également à Mademoiselle Nadia Tawbi. Professeur au département d9Informatique de l'université Laval, pour ses précieux conseils qu'elle m'a prodigués et pour avoir accepté d'être membre de ce jury.

Je voudrais remercier Sofiène et Norhène pour leur amitié et leur soutien moral qui n'ont jamais fait défaut et m'ont grandement aidé dans les moments difficiles.

Je remercie mes amis qui m'ont toujours soutenu et encouragé.

J e ne peux achever ces lignes sans présenter mes remerciements aux gens du CRIM

et en particulier les membres de l'unité MODL.

Table des matières

Table des matières vi

1 Introduction 2

1.1 Problématique et motivations . . . 3

.

1.2 Approches existantes . . . 3

1.3 Objectifs et contributions

. . .

⁴

Abstractions pour l'analyse de programmes 6 2.1 Analyse de programmes

. . .

6

2.2 Types d'analyse

. . .

6

'2.3 Abstractions utilisées pour I'analyse de programmes . . . 7

2.3.1 Généralités sur les graphes

. . . -

^I 2.3.2 Graphe de flot de contrôle

. . .

⁸

2.3.3 Graphe de dépendance

. . .

¹²

2.1 'Techniques d'analyse de flot de données et de contrôle . . . 18

2.5 Conclusion

. . .

18

3 Techniques de focalisation 20 3.1 Introduction . . . 20

3.2 Types d e focalisation statique

. . .

'21

3.3 Techniques de focalisation statique utilisant le GFC

. . .

21

3.3.1 Focalisation de base

. . .

21

3.3.2 Focalisation directe . . . 27

3.3.3 Focalisation de transformation

. . .

37

3.3.4 Focalisation de décomposition

. . .

32

. . . 3.3.5 Focalisation basée sur la pré-post spécification 34 3.4 Techniques de focalisation utilisant le GDP

. . .

37

3.4.1 Focalisation conditionnée

. . .

37

. . . 3 - 4 2 Technique de focalisation de Horwitz et ai 39 3.5 Conclusion

. . .

42

4 Abstraction du code pour la focalisation et les métriques 47 4.1 Vue globale de l'approche

. . .

⁴⁷

1.2 Abstractions pour les algorithmes de focalisation . . . 48

4 2 . 1 Base de faits D e f i f i e . . . 48

. . .

4 - 2 2 Base de faits des appels 50

. . .

4.2.3 Base d e faits des variables 52

4.3 Abstractions pour les métriques de profil

. . .

53 4.4 Cohésion fonctionnelle

. . .

57

. . .

4 Conclusion 60

5 Réalisation 61

. . .

5.1 Présentation générale du prototype 61

. . .

5.2 Fonctionndités du prototype 62

. . .

5.3.1 Génération du graphe de flot de contrôle 63

. . . 5 - 3 2 Focalisation de base intraprocédurale 63

. . .

5.2.3 Focalisation de PERFORM intraprocédurde 70

. . .

5 2.4 Focalisation descendante intraprocédurale 74 . . . L1-

5 - 2 3 Focalisation de transformation intraprocédurale ^{i I}

. . .

6 Focalisation directe intraprocédurale 78

. . .

5 . 2 . Focalisation de base interprocédurale 81

. . .

5.2.8 Problèmes rencontrés 8.5

. . .

5 - 2 9 Module métrique S-5

. . .

5.3 Conclusion S6

6 Conclusion 91

Liste des figures

2.1 Graphe de flot de contrôle intraprocédural

. . .

9

2.2 Graphe de contrôle interprocédural

. . .

11

2.3 Graphe Def-Use intraprocédural

. . .

13

2.1 Graphe Def-Use interprocédurd

. . .

11

2.5 Graphe de dépendance d'une procédure

. . .

17

2.6 Graphe de dépendance d'un système

. . .

19

3.1 Graphe de contrôle intraprocédural du programme . . . 2S 3.2 Graphe d e contrôle intraprocédural du slice

. . .

29

3.3 Processus d e la focalisation basée sur la pre-post spicification . . . 3.5 3 Grammaire des liens

. . .

40

3.5 Graphes des caractéristiques subordonnées

. . .

41

3.6 Graphe de dkpendance final . . . 43

3.7 Première étape de l'algorithme

. . .

44

3.8 Deuxième étape de l'algorithme . . . 45

3.9 %ce complet

. . .

46

1.1 Vue globale de l'approche . . . 48

5.1 :\Jenupn-ncipalduprotofype . . . 62

5.2 Exempk d'vn code COBOL

. . .

613

5.3 Boite de saisie de la couleur d e fond d'un slice . . . 64

5.4 Interface de saisie du critire de la f o c a l k t i o n de base

. . .

70

5

.

^{5 Fcnitre 1}

. . .

71

5.6 Fenêtre Y

. . .

II 5

.

⁷ Interface de saisie du critère de la focalisation de PERFORM . . . 713

. . .

5.8 Fengfre 3 73

. . .

5 9 Fenêtre

4

74 5.10 Interface de saisie d u critère de la focalisation descendante

. . .

76

C C

. . .

5.11 F ~ n E f r e 5 ^{I I} 5.1'2 Fenêtré 6

. . .

78

. . .

0.1.3 Fenêtre 7 1 9

. . .

5.14 Fengtr~ 8 ⁸⁰ 5-15 Interface dc saisie du critère de la focalisation de transformation

. . . .

81

. . .

5.16 Fenctrc 9 S I

. . .

5.17 FenEtre 10 S.3

LISTE DES FIGURES la

5 . 1 8 F e n ê t r e 1 1

. . .

84

. . .

5.19 Fenêtre 12 85

. . .

5.20 Fenêtre 13 86

. . .

5-21 Fenêtre 14 Si

. . .

5.22 Fenêtre 15 8s

. . .

5.23 Nombre de paragraphes et Profondeur du graphe d'appel 89

. . .

5.24 Métriques par paragraphe 89

. . .

5.25 Profondeur des structures de données 90

Chapitre 1 Introduction

1.1 Problématique ^et motivations

Durant le cycle de vie d'un système logiciel, quelle que soit sa taille. les besoins d'origine peuvent être modifiés? d'autres peuvent apparaître. l'environnement dans lequel il opère peut changer, comme on peut découvrir des erreurs que l'on n'avait pas vues durant la validation [Som92].

L'ent reprise qui utilise ce système se trouve alors devant deux alternatives: redévelap- per de nouveau Le système ou le maintenir.

La première alternative est généralement difficile à entreprendre et ce notamment pour les raisons suivantes:

Le système intègre un ensemble de connaissances substantielles sous forme de règles de décision et de gestion. Cet ensemble a été enrichi au fil des années et il est difficile: sinon impossible de le retrouver sans se référer au système existant [1\IPlrT94].

Faute de temps. il est généralement difficile de redévelopper un nouveau système qui reproduit l'ancien et y apporte les modifications requises en une courte pé- riode? surtout si celui-ci est gros et complexe. On retrouve ici le cas des projets de conversion de l'an 2000 [M\VT94].

Les coûts engendrés par la première alternative sont aussi importants. si ce n'est plus; que ceux engendrés par la deuxième [MWTS?].

De ce fait, la maintenance d u n système s'avère inévitable si on veut qu'il demeure utile.

Selon [FenSS, Som921, la maintenance peut être corrective. adaptative ou perfective.

Elle est. corrective si nous éliminons des erreurs q u e l'on n'avait pas encore découvertes.

Elle est adaptative si nous modifions le système pour qu'il tienne compte du changement de l'environnement. Elle est perfective si on ajoute d e nouvelles fonctionnalités au système actuel.

La maintenance est une tâche lourde pour le programmeur. En effet, il a été estimé que 50 % à 90 % des ressources sont consacrées au processus de maintenance [LC92, _Rug95, Sorn921. La compréhension des fonctionnalités du système est le facteur principal qui rend ce processus difficile et coûteux. D'ailleurs, Fjeldsatd et Homlen [Rug95, McC9'71 ont estimé que 47% à 62% des ressources allouées à améliorer et comger des programmes sont consommées en fait à comprendre ceux-ci.

Pour faciliter la compréhension du logiciel, on doit recourir aux techniques de ré- troingénierie. La rétroingénierie désigne le processus d'analyse d'un système: à pzrtir d'une description de bas niveau, afin de retrouver les composantes du système et leurs relations et de les représenter sous une forme de haut niveau d'abstraction plus facile à appréhender [RC93: EM93. LFM96: You96. Rug95j-

Ce processus n'est pas facile et dans [Rug95] on trouve quelques uns des facteurs les plus importants qui le compliquent, à savoir :

Le manque ou I'absence de documentation relative au système ;

L'écart entre le problème formulé dans le domaine de 1'applicat.ion et la solution proposée par le système. Même si on utilise des symboles de variables mnémo- niques ou des commentaires, le code d'un programme reste néanmoins difficile à comprendre. En effet. les commentaires et les symboles mnémoniques peuvent devenir obsolètes suite à des modifications répétées du code :

Les modifications apportées à un système ne sont pas généralement suivies d'une mise à jour des documents correspondants. Ces documents deviennent alors ob- solètes et ne reflètent plus les fonctionnalités courantes du système.

L'automatisation. même partielle. des techniques de rétroingénierie est d'un grand apport. Elle permet de les formaliser et de réduire aussi bien le temps q u e les coûts inhérents à la maintenance.

1.2 Approches existantes

La rétroingénierie peut. suivre une approche descendante (Top-down) ou une approche ascendante (Buttom-up) [LFM96, You96: Rug95].

L'approche descendante suppose que le programmeur a une idée des fonctionnalités du système, d'une part, et qu'une documentation soit disponible, d'autre part. Le programmeur cherche dans ce cas, à faire correspondre les éléments conceptuels aux concepts qui se trouvent dans le code source.

Ii

procède par une formulation d'hypothèses de plus en plus détaillées qu'il valide jusqu'à retrouver la structure du code.

L'approche ascendante. par contre, est utilisée lorsque le programmeur n'a aucune information sur les fonctionnalités du système et ne dispose q u e du code source.

Cette approche consiste à partir du code pour construire d'une manière itérative des modèles de niveaux d7abst,raction plus élevés. Cette approche est moins tributaire

Introduction 4

d'une expertise sur le domaine d'application et par conséquent, elle est plus facilement automatisable.

Dans le cadre de l'approche ascendante, une analyse du code basée uniquement sur les commentaires, les symboles mnémoniques et les indentations n'est ni suffisante, ni fiable. En effet, comme nous l'avons mentionné, ces éléments peuvent être obsolètes et informels et par conséquent seules les instructions constituent un élément pertinent pour la compréhension du code du fait qu'elles reflètent les fonctionnalités réelles du système.

L'analyse d h n code peut être statique ou dynamique. L'analyse statique considère le texte en entier sans se référer à une exécution particulière et elle est utilisée notamment pour la compréhension. Alors que l'analyse dynamique s'intéresse au code relativement à une exécution. À l'opposé de l'analyse dynamique, l'analyse statique privilégie la généraJité, ce qui peut se faire au détriment d e la précision. D'une manière générale.

I'utilisation d e l'analyse dynamique est plus orientée vers le test e t le débogage.

1.3 Objectifs ^et contributions

Ce projet a trois objectifs majeurs. Le premier est de fournir pour des sytèmes

COBOL un ensemble d'informations pertinentes sous la forme d'abstractions. Ces abstractions serviront à la redocumentation ou même à la documentation des sys- tèmes à maintenir. Les mêmes abstractions peuvent être également exploitées par des algorithmes d'analyse statique du code telles que les techniques de focalisation statique. Le deuxième objectif est de concevoir un outil d'analyse statique facilitant la compréhension de systèmes COBOL. Enfin. le troisième objectif consiste & fournir des métriques qui permettrons de valider l'out il développé. Ces métriques considèreront la cohésion fonctionnelle ainsi que des métriques traçant le profil des systèmes analysés.

Les contributions de ce projet sont triples. Tout d'abord. nous avons conçu et développé des extracteurs ci'abstractions de systèmes COBOL. Les abstractions sont sous forme de base de faits ce qui offre une souplesse d'adaptation des différents outils les utilisant, à d'autres languages de programmation que COBOL. Basé sur ces abstractions, nons avons conçu et implanté un prototype intégrant un ensemble de techniques de focalisation statique. Ce prototype permet de faciliter non seulement la compréhension des systèmes mais également leur modularisation, leur réutilisation, etc. Le choix d'une approche ascendante pour le processus de compréhension est justifié par l'absence de d0cument.s décrivant les programmes à analyser ou de toute autre informat ion pertinente en dehors du code. Les résultats d'une telle recherche pourront être directement intégrés au sein d'un ensemble plus vaste d e techniques de rétroingénierie. Enfin, nous avons proposé des métriques pour la vérification de ce prototype telles que le calcul de Ia cohésion fonctionnelle à l'aide d e slices. Nous axons aussi développé les extracteurs correspondant.^ à ces métriques.

Ce mémoire commence par une introduction présentée dans Chapitre 1 et se termine par une conclusion présentée Chapitre 6 . Dans Chapi tre3, nous présentons les notions d e bases relatives à l'analyse de programmes, à savoir les différents types d'analyse et les abstractions utilisées par ceux-ci. Dans Chapitre 3, nous passons en revue une famille des techniques d'analyse statique en l'occurrence les techniques de focalisation statique. Nous donnons la définition de la notion de focalisation et nous présentons les techniques les plus importantes. Dans Chapitre 4, nous présentons les abstractions nécessaires à l'implantation de certaines techniques de i~calisation que nous avons choisies ainsi que des extracteurs correspondants. Nous définissons également des métriques de profil et une métrique de cohésion fonctionnelle. Pour chaque métrique de profil nous donnons les extracteurs permettant de les mesurer.

Enfin. dans Chapitre 5, nous décrivons le prototype de focalisation développé et les algorithmes de ses différentes fonctionnalités.

Chapitre 2

Abstractions pour l'analyse de programmes

Dans ce chapitre: nous nous intéressons à l'analyse de programmes et plus particulière- ment' aux abstractions utilisées par celle- ci. Nous cornmencons par présenter ta notion d'analyse de programme? ainsi que les différents types d'analyse tels que proposés dans la littérature. Ensui t e nous présentons les abstractions utilisées par ces analyses tant au niveau intraprocédural qu'interprocédural.

2.1 Analyse de programmes

L'analyse de programmes est un outil important pour le génie logiciel. Elle détermine si le programme vérifie une propriété donnée ou extrait des informations de celui-ci [GouSij. Elle peut aller d'une simple analyse lexicale du code jusqu'à l'anal-se du comportement du programme.

Deus grands domaines utilisent les techniques d'analyse du code. Le premier est la compilation. Les compilateurs utilisent ces techniques notamment pour vérifier.

générer et optimiser le code.

Le deuxième domaine d'application, est la maintenance du logiciel. En effet. le développement d'applications de grande taille et souvent complexes, rend nécessaire l'utilisation d'outils de plus en plus sophistiqués pour la conception: le test et La maintenance de ces applications [Gougl].

2.2 Types d'analyse

Les analyses proposées dans la littérature, aussi diverses soient-elles, présentent des caractérist.iques communes et peuvent être classsifiées. Une première classification pos- si ble consiste à distinguer entre l'analyse statique e t l'analyse dynamique.

Abstractions ^pour l 'anaZyse de propi~mmes 7

0 L'analyse statique est l'examen systématique de l a structure d'un programme dans le but d e montrer que certaines propriétés sont vraies quelque soit le chemin suivi lors de l'exécution d e ce programme

[Oh961 .

0 L'analyse dynamique par contre, consiste à étudier le comportement effectif d'un programme. En effet, elle ne considère dans le code que la partie qui sera exécutée par rapport à une valeur d'entrée particulière d u programme.

L'analyse dynamique constitue un complément significatif de l'analyse statique. Elle facilite considérablement le diagnostic d'erreurs, le typage dynamique, le débogage, le test, etc.

Une autre classification peut se faire suivant que l'analyse est intraprocédurale ou interprocéduraie. Une analyse est dite intraprocédurale lorsqu'elle traite un module P

sans t-raiter les relations d'appel. Elle est dite interprocédurale. sinon.

Enfin. une analyse peut traiter le flot de données ou le flot de contrôle. Une analyse du flot de contrôle s'intéresse à l'ordre d'exécution des instructions, alors qu'une analyse d u flot de données s'intéresse à l'évolution des valeurs que prennent les variables et leurs utiiisations.

2.3 Abstractions utilisées pour l'analyse de pro- grammes

Les techniques d'analyse de programme se base entre autres sur la théorie des graphes.

La structure du code peut être représentée par un graphe orienté appelé graphe de Bot de contrôle (GFC) [LV96, CFV93, LkiS-l, HU96, BG96] intraprocédural pour un seul module et interprocédural pour tout uri système. Dans ce qui suit, nous donnons les définit ions des concepts utilisés dans les différent es techniques de focalisation.

2.3.1 Généralités sur les graphes

2.3.1 Définition. [Graphe orienté]

Un graphe orienté G est une paire ( N , A ) , où N est l'ensemble des noeuds e t -4 l'en- semble des arcs tels que A

C

I\; x N .

Si un arc (ni, nj) E .4 alors ni est appelé prédécesseur immédiat de n, e t nj est le successeur immédiat de ni.

On désigne par pred(n) l'ensemble des prédécesseurs immédiats de n et suc+) l'ensemble de ses successeurs immédiats.

Par in(n), on désigne le nombre des prédécesseurs immédiats de n et par o u t ( n ) le nombre de ses successeurs immédiats.

Un chemin

C

noté ni-nk de

G

est une séquence de noeuds nln2

...

^nk, tel que (ni: n j ) ^E -4 pour 1

5

ⁱ

< ^Fi.

Abstractions pour 1'a.rzaJyse de programmes 8 2.3.2 Définition. [Graphe "harnmock"]

U n

graphe "hammockf' G est un graphe orienté qui a un noeud initial nr et un noeud final n~ tel que:

1. in(nr)=O et out(nF)=O.

2. Vn E

EG,

n appartient à un chemin n l - n ~ .

Les noeuds d'un graphe orienté sont régis par la relation d e dominance.

2.3.3 Définition.[Dominance]

Soient G un graphe "hammock" et m , n deux noeuds. Le noeud n est dominé par m si e t seulement si tout chemin n - n~ contient m. L'ensemble des dominateurs de n est noté F D ( n ) .

On dit que rn est le dominateur immédiat de n si et seulement si m est le premier noeud qui domine par n sur tout les chemins n - n ~ et n

#

m. Le dominateur immédiat de n est noté i f d ( n ) .

2.3.2 Graphe de _flot de contrôle

2.3.4 Définition. [GFC intraprocédural]

Un graphe de flot de contrôle intraprocédural C; est un graphe "harnmock" q u i repré- sente une procédure. où les noeuds sont des instructions élémentaires et où les arcs représentent un flot de contrôle ^entre les instructions.

2.3.5 Exemple. Considirons u n programme qui calcule la somme e t le produit d e s n premiers nombres d a n s u n e même boucle.

1. begin

read (n) ; i f n>O then begin

i := 1;

s u : = O ; p r o d : = 1 ;

while iC=n do begin

read (k);

sum : = s m + k ; prod := prod*k;

i := i+l;

end ;

write ( s u ) ; write (prod) ; end ;

Le graphe d e flot de contrôk correspondent est représente dans la figure 2.1.

Abstractions pour l'analyse de programmes 9

Abstractions pour l 'anaiyse de progammes 10

Au niveau interprocédural, le niveau d'abstraction n'est plus une instruction. mais plutôt une procédure et les relations entre les procédures d'un système.

2.3.6 Définition. [GFC int erprocédural]

Un graphe de contrôle interprocédural est un uplet

(Gi, ... 'Gt,

CALL? RET), ^où Gi est un graphe de contrôle intraprocédural représentant une procédure; CAL L I'en- semble des arcs d'appel et

RET

I'ensemble des arcs de retour, tels que:

1. un arc d'appel de

G i

à G, est de la forme ( n , n r ) avec n une instruction d'appel dans

Gi

et nr le noeud initial de G,;

2. un axc de retour de Gj à

Gi

est de la forme (nFo n ) , tel que n~ est le noeud final de

Gj

et n une instruction d'appel de

Gi;

3. pour chaque arc d'appel (n' nI), il existe un arc de retour ^{( n F ,} n ) tel que nr et n~ sont les noeuds initial et final de la même procédure.

2.3.7 ExempIe. Soif Zr aysfèrn~ f o n n i des prockdures suirantes:

1

.

P r o c e d u r e Main 2 . i := 1;

3 . sum:= O ;

4. while i < l l do 5. Call A(sum, i);

6. end

7 , p r i n t ( s u ) 8 . e n d

9 . Procedure A (x, y) 1 0 . Call Add(x, y);

11

.

^{Call Increment} (y) ;

12 - return

13.Procedure Add(a, b) 14. a:= a+b;

15. r e t u r n

16. Procedure Increment ⁽²⁾ 17. Call Add(z, 1) ;

18. r e t u r n

L a

figure 2.2 reprisente le graphe de contrôle interprocédural du système.

En plus de la notion de dominance, on trouve dans le graphe de flot de contrôle la notion d'instructions condit ionnées.

A bstractions pour I 'analyse de programmes 11

Figure 2.2: Graphe de contrôle interprocédu+ul

Abstractions pour I'analvse de proprammes 12

2.3.8 Définition.[Instruction conditionnée]

Soit G un graphe de contrôle et n un noeud de G. Une instruction rn est conditionnée par ⁿ si e t seulement si m se trouve dans le chemin n

-

i f d ( n ) et rn

#

ⁿ et rn

4.

i fd(n)-

L'ensemble des instructions conditionnées par ⁿ est dénoté par in f l ( n ) (influence).

En

fait, n représente une instruction conditionnelle et par suite, si out(n)

5

1 alors in f l ( n ) est vide.

En plus de la structure du code et l'ordre d'exécution des instructions? on peut également ajouter au GFC des informations relatives à la définition e t à l'utilisation des variables, le graphe résultant est appelé graphe Def/Use.

Ces informations permettent notamment. une analyse de la durée d e vie des variables du programme [Gougï]. L'analyse de la durée de vie détermine pour tout point du programme l'ensemble des variables vivant,es.

Une

vâriable v est dite vivante en un point i si la valeur de v en i est utilisée sur un chemin du G F C partant de i. Une variable non vivante est qualifiée de morte.

2.3.9 Définition.[Graphe Def/Use intraprocédural]

Un graphe Def,XJse intraprocédural G est un graphe de contrôle, où chaque noeud n est annoté par l'ensemble des variables utilisées

U(n)

et de l'ensemble des variables définies D ( n ) .

On dit qu-une variable x est définie dans une instruction ^S. si s lui assigne une valeur. alors que x est dite utilisée par s si elle a besoin d'évaluer x.

2.3.10 Exemple.

La

figure 2.9 r c p r k e r i t e Ze graphe D%'li's~ de I éxernple 2.9.5.

2.3.11 Définition.[Graphe Def/Use interprocédural]

L-n graphe DefjUse interprocédural est un graphe de flot de contrôle interprocédural d'un système, où chaque noeud est annoté par l'ensemble des variables utilisées L-(n ) et celui des variables définies D ( n ) .

Pour une instruction d'appel n,ir dans

Gi;

x E Li(nmri) si l'exécution de

G i

requiert l'évaluation de r - Alors que x E D(nCall ) si I'esécution de G, affecte une valeur à x.

2.3.12 Exemple. La figure 2.4 reprisente le graphe DeJ!'Use du système de i'eremple

Y.

3.7.

2.3.3 Graphe de dependance

Un autre type de graphe orienté est utilisé par les techniques d'analyse de programme :

le graphe de dépendance de programme [CCLLM, HRBSO, BG96, LC92. Lak91. Lak921.

Contrairement au GFC, le graphe de dépendance ne représente pas l'ordre d'exécution des instructions mais les différents types de dépendance entre les instructions (noeuds du graphe).

2.3.13 Définition. [Graphe de dépendance intraprocédural]

Le graphe de dépendance d'une procédure P tel que utilisé par les techniques de focalisation abordées dans ce mémoire. dénoté par G p est un graphe orienté ( N ;

A),

A bstractioos pour I 'analyse de programmes 13

Figure 2.3: Graphe Def-L'se intraprocidural

Abstractions pour 1 'analyse de vromammes 14

Arc d'appel

- - -. Arcderetour

Figure

2.4:

Graphe Def- Use interprocédural

A bstractions pour I'analyse de programmes 15

Ri

étant I'ensemble des noeuds d u graphe et A celui des arcs [EIRBSO].

Les types de noeuds du graphe sont:

un noeud pour chaque instruction d'affectation:

a un noeud pour chaque prédicat de contrôle (d'une conditionnelle ou d'une boucle);

un noeud entrée pour marquer le début d'une procédure;

un noeud appelé "Définition initiale" d'une variable pour dénoter la première affectation de cet te variable:

un noeud appelé "Utilisation finale" d'une variable pour dénoter un accès à la dernière valeur calculée de cette variable.

Pour ce qui est des arcs' il y a deus types:

a l'arc de dépendance de contrôle libellé True ou False;

l'arc de dépendance de données.

2.3.14 Définition. [Dépendance de contrôle]

11 esiste un arc de dépendance de contrôle d'un noeud cl à un noeud v2 e t on note

r.1

-+,

^~2 si et seulement si:

a v l est un noeud entrée e t v2 représente une instruction non imbriquée dans une boucle ou une conditionnelle. L'arc dans ce cas est libellé True,

e vl est u n noeud prédicat et 2.2 représente une instruction imbriquée dans la boucle ou la condit.ionnel1e relative à v l . Si vl est le prédicat d'une boucle d o r s l'arc est libellé True' si par contre il est le prédicat d'une conditionnelle alors l'arc est libellé T h e pour la branche Then. False sinon.

2.3.15 Définition. [Dépendance de données]

Un arc de dépendance de données de cl à z;z traduit que le calcul pourra être modifié si les instructions représentées par vl et v2 sont permutées.

11 existe deux types de dépendance de données:

e

La

dipendance de flot:

Il y a dépendance de flot de q à t.2 et on note cl +f zY2 si et seulement si:

- représente une instruction qui définit x;

-

^{v 2} représente une instruction qui utilise x;

-

il existe un chemin d'exécution par lequel Ia définition de x dans vl atteint son utilisation dans zY2-

Abstractions pour I 'malyse de programmes 16

Une dépendance de flot peut ê t r e dépendante ou indépendante d'une boucle.

-

Elle est dépendante d'une boucle et est notée ut -ti,(s) ^vl (Ic: loop carried et L: Loop) si et seulement si: en plus des conditions sus-citées, les conditions suivantes sont satisfaites:

*

^{v l} et v? sont encapsulées dans la même boucle L;

*

il existe un chemin d'exécution qui satisfait la troisième condition et comprenant un arc d e retour vers Leprédicat d e la boucle.

- Elle est indépendante d e la boucle et est notée vl - t i i vn (li: Ioop indepen- dent) si e t seulement si, en plus des trois premières conditions, il existe un chemin d'exécution qui sat,isfait la troisième condition et qui ne comprend pas un arc de retour au prédicat de la boucle qui encapsule ^{V I} et

Q.

La d é p e n d a n c e d~j-order:

Il existe une dépendance def-order de ^u1 à v* qu'on note par ^{v l} + d o ( u 3 ) V*

si et seulement si:

-

^{u l et 2'2} définissent une même variable:

- u 1 et r1 se trouvent dans une même branche d h n e conditionnelle:

- il existe une instruction représentée par V I telle que v l + J us et v 2 ++J u3:

- al se trouve à la gauche d e ^c2 dans l'arbre syntaxique du programme.

2.3.16 Exemple. On remplace l'appel de A d a n s le programme principal Main de 1 ' ~ r e r n p l e 2.9.7 par l e s d c v t i n s t r u c t i o n s s u i c a n t e s : sum :=sum+i suirie de i : =i+l. Le graphe d e d g p m d a n c e correspondant est r e p r é s e n t e par la figure 2.5.

2.3.17 Définition.[Graphe de dépendance interprocédural]

Le graphe de dépendance interprocédural n'est autre qu'une extension du graphe de dépendance intraprocédural. En effet. il s'agit de relier les graphes d e dépendance d e chacune des procédures du système par un ajout de nouveaux noeuds et arcs qui modélisent les appels de procédures.

Dans le cas du passage de paramètres par valeur, lorsqu'une procédure P appelle une procédure Q. le passage des paramètres se fait par le biais de variables tempo- raires. En effet, avant l'appel, P copie les valeurs de ses paramètres réels dans des kariables temporaires: Q initialise par la suite ses paramètres à partir d e ces variables temporaires.

Avant de retourner le résultat à P , Q copie les valeurs à retourner dans d'autres vari ables temporaires desquelles P estrai t le résultat.

Par conséquent, les noeuds qui seront ajoutés sont les suivants:

un noeud d'appel pour chaque instruction d'appel;

Abstractions pour l'analyse de ~ r o ~ ~ a x m n e s 17

-

Dependance de contrôle

-

Dépendance de flot indépendante d'une boucle Dépendance de flot dépendanie d'une boucle

- Dépendance DefIOrder

Figure 2.5: Graphe de dipendance d ' u n e procédure

u n noeud kctual-in" qui représente l'affectation du paramètre réel de P à une variable temporaire généralement noté "nom de la variable temporairein--:

un noeud nactuai-ouf" qui représente l'affectation de ^la variable temporaire pro- venant d e Q e t noté &nom de la variable temporaire-out", a u paramètre réel de P:

u n noeud *formal-in" qui représente I'affectation du temporaire provenant de P a u paramètre formel d e Q;

un noeud Lfonal-out'' qui représente l'affectation du paramètre formel de Q à la variable temporaire.

Les nouveaux arcs qui seront ajoutés sont:

un arc d'appel d e chaque noeud d'appel au noeud entrée de la procédure appelée.

il est d u type contrôle;

a un arc "paramefer-in' d e chaque noeud 'actual-in' a u noeud

or mal-in'

^corres-

pondant, il est d u type données:

e un arc "parameter-oui ^" de chaque noeud "fonnal-out

-

^{au noeud} -actual-ouf"

correspondant, il est du type données.

Abstractions pour

I

^'analyse de programmes 18

2.3.18 Exemple. La ^figure 2.6 représente les graphes de dépendance des diferentes procédures du système de l'exemple 2.3.7 reliés par les arcs Gparameter-in", Yparameter- ouf' et les ^arcs d 'appe.

2.4 Techniques d'analyse de flot de données et de contrôle

La compilation utilise l'analyse de flot de données de contrôle notamment lors de l'op- timisation du code. Une telle analyse permet d'améliorer l'efficacité du programme.

Xous trouvons également les techniques de focalisation plus connues sous le nom d e techniques de slicing. Cette analyse sert à filtrer les instructions d'un code et n'en gar- der que celles qui vérifient un critère fixé auparavant.

L'utilisation des techniques de focalisation est multiple. On trouve notamment. le dé- bogage. la compréhension. la parallélisation, le test. les métriques. la réutilisation e t l'intégration.

Notre objectif étant de faciliter le processus de compréhension. nous nous intéressons dans ce travail aux techniques de focalisation.

De plus. pour ce faire. nous allons nous baser uniquement sur le code. Par conséquent.

nous nous limiterons à l'étude des techniques de focalisation statique que nous allons présenter dans le chapitre qui suit .

2.5 Conclusion

Dans ce chapitre nous avons passé en revue les notions de base relatives à l'analyse de programmes. Xous avons vu qu'il esiste deux types d'analyse de programme : l'analyse statique et l'analyse dynamique. Le premier type sert à la compréhension alors q u e le deuxième type sert plus au test et au débogage. Kous avons identifié deux types d'abstractions utilisées par les différentes techniques d'analyse. à savoir le graphe de flot de contrôle et le graphe de dépendance. Dans le chapitre suivant. nous nous intéressons à une famille de techniques d'analyse, à savoir les techniques de focalisation et plus particulièrement les techniques de focalisation statique. La focalisation statique permet entre autre de faciliter la compréhension en identifiant les fonctionnalités du système.

Abstractions pour l'analyse de programmes ¹⁹

-

^Conuôlt

-t Rot indtpcndant d'une boucle Fiot dépendant d'une boucle

--

_APL'~~

PYamiire-in Parameue-out

Figure 2.6: Graphe de dépendance d ù n système

Chapitre 3

Techniques de focalisation

Dans ce chapitre, nous nous intéressons à une famille de techniques d'analyse statique : les techniques de focalisation statique. Sous ne présentons que les techniques les plus connues. notamment la focalisation de base, la focalisation de transformation et la focalisation conditionnée. Nous commençons par définir la notion de focalisation et ses différents types. Les différentes techniques sont catégorisées selon les abstractions qu'elles utilisent. Pour chaque technique. nous donnons ses objectifs. son algorithme et ses points faibles.

3.1 Introduction

La focalisation est une technique d'analyse de programme qui permet au mainteneur de localiser et de comprendre les fonctionnalités d'un système à partir d'un graphe Def'Use ou d'un graphe de dépendance. Cette technique est plus connue sous le nom de siicing [SEIi93. CL519.5].

En 19Y.d' L.\-eiser [\VeiS4] a proposé la première technique de focalisation. à savoir la focalisation de base. La focalisation de base désigne la décomposition automatique du code pour en extraire toutes les instructions qui peuvent affecter le calcul d h n ensemble de variables ^{l a / '} a u niveau d'une instruct.ion i. On appelle le sous-ensemble des instructions obtenu un slice. Le couple (i, C') constitue le critère de focalisation qui specifie le slice.

La focalisation est actuellement utilisée dans de nombreux domaines notamment le débogage [WeiS4]. En effet, si la valeur d'une variable n'est pas correcte alors l'erreur se trouve dans son slice. D'autres domaines sont aussi importants tels que la compréhension [HDS95], la modularisation et la parallélisation [BG96, LCSZ, LFM96].

Avec la diversité des applications de cette technique, d'autres algorithmes ont été proposés avec de nouvelles définitions pour les notions de slice e t de crit2re.

La focalisation peut être statique ou dynamique. La première sert à la compréhen- sion alors que la deuxième sert au débogage. Nous allons donc focaliser notre attention

Techni~ ues de focalisation 21

sur le slicing statique.

3.2 Types de focalisation statique

La distinction entre les différentes techniques de focalisation peut se faire suivant la stratégie de l'algorithme adopté, la nature du slice obtenu. ou de la structure du critère.

Un algorithme de focalisation peut suime une approche ascendante ou descendante [NEK93].

La première approche répond à la question 'Quelles sont les instructions qui affectent potentiellement le calcul d'un ensemble de variables V au niveau d'une instruction

S.?".

L e deuxième type répond à la question "Quelles sont les instructions qui sont affectées par !a valeur de la variable

V

au niveau d'une instruction s?".

Quant au slice généré. il peut être un programme exécutable ou juste un sous-ensemble d'instructions. Dans le premier cas, le slice reproduit une partie des fonctionnalités d u système analysé. Dans le deuxième. le slice est un sous-ensemble des instructions du code sans qu'il soit nécessairement exécutable.

Il est plus simple de générer un sous-ensemble d'instructions qu'un programme exécutable- Toutefois. le dernier est plus utile. en effet: sur un slice exécutable on peut appliquer d'autres techniques d'analyse pour obtenir une information plus précise.

A tout critère correspond au moins un slicc qui est le système entier.

Un autre critère d e distinction est le type d'abstraction utilisé. En effet. on trouve les techniques utilisant le graphe Def/lise et celles utilisant le graphe de dépendance de programme (GDP) tels que décrits dans Chapitre 2.

C'est sur ce dernier critère que nous allons nous baser pour présenter les techniques les plus importantes de la focalisation statique.

3.3 Techniques de focalisation statique utilisant le GFC

3.3.1 Focalisation de base

Cette technique a été définie par Hféiser [WeiM]. Elle est essentiellement utilisée pour la compréhension grâce à une décomposition du code permettant d'obtenir des modules plus cohésifs et par suite plus compréhensibles.

Le critère utilisé est de la forme C = (s, I,'), avec s le numéro de ligne d'une instruction et

V

un sous-ensemble de variables du programme. tous deux choisis selon les besoins de l'analyse.

Le processus de recherche des instructions du slice est un processus itératif et se base sur un système d%quations de flot de données [LV96, Wei84, BG961.

Techniques de focdisa ^t ion 32 La focalisation de base intraprocédurale

Le calcul du &CE commence par la recherche des variables directement pertinentes aux variables du critère et ce pour chaque instruction qui précède L'instruction du critère dans le GFC.

L'ensemble des variables directement pertinentes au niveau d'une instruction n est défini comme suit :

P,(n)

= { u E V

1

n = s )

u

{ u E U ( n )

1

D ( n )

n

g ( s u c c ( n ) )

+

0)

ü {@(succ(n))

\

D ( n ) ) . avec succ(n) l'ensemble des successeurs d e n

Le premier sous-ensemble est l'ensemble de base. Ce sont les variables directement pertinentes à loinst ruction du critère.

Le deuxième sous-ensemble stipule que les variables ayant servi à la définition d e variables directement pertinentes au(x) successeur(s) de n sont aussi pertinentes au niveau de n.

Le troisième sous-ensemble exclut les variables qui sont pertinentes au(x) successeur(s) et qui sont définies au niveau de n. Ces variables ne sont plus pertinentes a+) prédécesseur(s) de n.

-4 partir des

ROC

on cherche l'ensemble SF des instructions directement pertinentes.

Ce sont les instructions qui définissent les variables directement pertinentes à leurs successeurs:

Cet ensemble n'englobe pas les instructions conditionnelles qui contrôlent l'exécution des instructions qui se trouvent dans Sg. L'ensemble de ces instructions dénoté par BE est défini ainsi:

Les variables utilisées dans les instructions conditionnelles ainsi que toutes les va- riabIes qui leur sont pertinentes sont dites indirectement pertinentes à V et sont cal- culées dans l'ensemble R$' ( n ) :

Ces

RF'

permet tent de chercher par la suite I'ensemble des instructions indirectement pertinentes.

Technig

ues de focalisation 23

Ces trois derniers ensembles sont recdculés tant que ^1'011n'a pas atteint un point fixe pour ~$'(n) ce qui est équivalent à un point fixe pour Sc*'. Ce point fixe constituera le slice cherché par rapport au critère C: en d'autres termes il n'existe plus de variables pertinentes aux variables du critère e t donc il n'y a plus de nouvelles instructions qui s'ajoutent à l'ensemble Si? Ce point fixe existe puisque l'ensemble des instructions et des variables d'un programme sont finis (sauf dans le cas de la récursivité).

Plus formellement, un slice est

s ~ = s ~ * '

^{tel pue Vn 'n} N : : a n ) = &(n) =

R&).

3.3.1 Exemple.

Si

nous focaiisons le programme de léxemple 2 3 . 5 avec ZE critère C = (15, {sum)), nous obtenons les ensembles suivants:

ROc(15) = { s u m }

@(13) = { s u m } ( 1 ) = { s u m ) Ro,(ll) = { k , s u m ) ROc(lO) = ( s u m ) RC(S) ⁼ { s u m ) G(7) = { s u m )

@(6) =

0

ROc(5) =

0

G(3)

⁼

⁰

@(2) =

0

q 8 . {i. n}) ( 8 ) = {i. n )

{*. ,}) ( 13) = {i? n )

8 . j . 1 =

G-

ⁿ⁾

Rh(15) = { s u m )

Rb-13)

= {i: n. s u m } Rk(12) = {i, n , s u m ) RL(I.1) = {il n , k, _{s u m )} RC.10) = {i, n o s u m )

Techniques de focdisa tion 24

De merne, on trouve que : V n E N ^:

RC(n)

= R,i(n).

On en dcduit que Sc = S: = (2. 3: 5. 6, 8. 10' 11, 13).

La focalisation de base int erprocédurale

Si on effectue une focalisation sur un module P qui est appelé par un autre module Q ou qui appelle un module R. le critère d'origine doit être transformé par rapport au conteste de Q e t R. Le s l i c ~ doit préserver les instructions des modules appelants et appelés.

La techniques de i+7eiser pour la focalisation interprocédurale s'effectue en deux étapes.

La première étape est la focalisation intraprocédurale du module P avec Le critère d'origine. Une instruction d'appel à un module Q dans P est traitée comme toute autre instructiont c'est à dire chercher les variables utilisées et celles définies en remplaçant les paramètres formelles par les paramètres réelles.

Ce genre de calcul donne des résultats imprécis et le sllce peut ne pas être minimal.

Ceci est d û au fait que CVeiser n e prend pas en considération la correspondance entre les \-ariables définies et celles utilisées.

Ce problème est illustré par l'exemple suivant :

3.3.2 Exemple.

Soit

le systérnc suivant:

program Exemple 1. begin

2. a:= 17;

3 . b:= 18;

4. P ( a , b , c , d ) ;

5. ~ r i t e ( d ) ; 6. p r i n t ( s u ) 7 . end

Procedure P ( v , w, x, y) 8. x:= v ;

9. y : = w;

IO. end

Techniques de focalisation 25

Focalisons le programme principale Exemple avec le critère C = (5: d).

On

ob- tient:

program Exemple 1

-

begin

2 - a:= 17;

3. b := 18;

4- P ( a , b , c , d ) ; 6. p r i n t (sum) 7. end

P r o c e d u r e P ( v , a , x, y) 9. y:= w;

10. end

L Ynstruction de la ligne 2 ne devrait pas Etre dans le ^s iant. nous n'acons pas d Z n f o n a t i o n s qui montrent que la cariabZe b a &te utilisEe pour dififinir d d a n s P. ce q u i explique ['appartenance de cette instruction au slicc final.

La deuxième étape consiste à générer de nouveaux critères pour les modules appelants et appelés par P.

Les deus étape seront répétées jusqu'à ce qu'aucun nouveau critère n e soit généré.

Le critère correspondant à u n module R appelé par P au niveau de l'instruction i est:

où T ~ F R est la dernière instruction de

R1

F -t -1 remplace les paramètres réels par les

paramét res formels dans:

e t s c o p e ~ est l'ensemble des variables accessibles à partir de R. Ce sont toutes les variables utilisées par R.

Pour un module Q appelant P au niveau d'une instruction i. le critère corres- pondant est:

Les variables du critère sont celles accessibles par Q et qui seront pertinentes dans P.

Soit C le critère de départ. L'ensemble des critères pour focaliser les modules appe- lant P est dénoté par 0 - P ( C ) . L'ensemble des critères pour focaliser les modules appelés par P est dénoté par D O W N ( C ) .

La fermeture transit ive ( U P U DOCV7N)' (C) contient tous les critères nécessaires pour faire une focalisation interprocédurale d'un système à partir du critère d'origine C.

Techniques de focalisation 26

Cette étape présente également un problème, celui du contexte d'appel que nous verrons dans l'exemple suivant.

3.3.3 Exemple. Considérons le système formé des procédures suivantes:

1. Procedure Main 2. i := 1;

3 . sum:= 1;

4. while i

<

100 do 5. i := i + 2 ;

6. CallA(sum, i);

7. od

8. print ( s u ) 9. end

10.Procedure A(x, y) 11. C a l l ~ d d ( x , y);

12. Call Inc(y) ; 13. return

14. Procedure Add (a, b) 15. a:= a+5;

16. return

17.Procedure Inc(z) 18. C a l l ~dd(z, 1);

19 .return

Lorsque nous focaiisons ce s y s t i r n e arec u n critère de départ C = (12.

{Y)):

on aura les ~ n s e r n b l r s et les critires suivants:

Sc = 0

DOI,l;-iV(C) = ((16. ( 6 ) ) ) l i P ( C ) = ((6. {i)))

Si le critère ^initial est C = (Dernière instruction de Inc, ^{r)), Increment appelle Add donc Add sera focalisie avec le critère Cf = (Dernière instruction de rldd. { a } ) . Cette d e m i i r e aant ^appelee aussi bien par A que par Incrernent, alors on obtiendra les deux c,ritires Ci = (-4ppel de Add d a n s Inc, { r ) ) e t C2 ⁼ (Appel de A d d dans -4- {x))

Techniques de focalisation 2'7

o r ce dernier ne doit pas être p r i s en compte puisque Add doit retourner à Inc. Cést ce qu 'on appelle "Problème du contexte d'appel".

Nous remarquons alors, que

U P ( C )

ne doit être calculé que pour le critère d'ori- gine C. Plusieurs solutions ont été proposées pour résoudre le problème du contexte d'appel notamment, I'utilisation d'un GDP a u lieu du GFC' tel que dans l'algorithme de Horwitz et al.[HRBSO].

Une

deuxième solution consiste à remplacer les appels par le code des modules appelés. Cette dernière solution s'avère inapplicable dans le cas des appels récursifs.

3.3.2 Focalisation directe

La focalisation directe sert à extraire des composantes relatives à l'environnement d'implantation et à l'interface [CFV93]. L e fait que ces composantes sont dispersées dans le code n'aide pas à sa compréhension. Les outils eristants pour l'extraction et l'abstraction de composantes se basent essentiellement sur la structure du code et par

ce cas.

suite ils ne peuvent être appliqués dan-

En facilitant la migration du même système vers différentes plat eformes' la focalisation directe permet de mieux comprendre le code et de réduire les coûts d e la maintenance adaptative et perfective .

Le critère utilisé pour cette technique est de la même forme que pour la focalisation de base. à savoir C = ( S . l-fv). Toutefois. la définition du slice ne sera plus la même. En effet. le s l i c ~ Sc est l'ensemble des instructions qui affectent seulement d'une manière directe le calcul d e I.,- au niveau de s et les instructions conditionnelles qui contrôlent leur exécution. Par affectations directes, nous désignons les dernières assignat ions faites à des variables de 6. Par conséquent

s:''~~' E

3.3.4 Exemple. Soit le graphe d e contrôle de la figure 3.1, la jïgure 3.2 r ~ p r i s e n t e le graphe ^de contrôle d u slice direct obtenu sous IE critère C = (21. { a . 6 .

f.

i. _{l } ) .}

3.3.3 Focalisation de transformation

La focalisation d e transformation sert à isoler les composantes réutilisables d'un système [LV96]. En effet, une composante réutilisable est spécifiée par sa dernière instruction s, ses variables d'entrée \.$, et ses variables de sortie C.gut. On retrouve ces trois éléments dans le critère de cette technique C = ^(S.

Vin. V i u t ) -

Avec ce critère. nous obtenons un slice défini comme l'ensemble des instructions qui transforment 1 'ensenble des vari ables d'entrée

x,

en l'ensemble des variables de sortie VQUt au niveau de S. Dans cet ensemble, nous ne considèrerons ni les instructions qui définissent les variables

K,,

ni les tests qui contrôlent l'exécution de la composante à

extraire.

Le principe de recherche du slice pour la focalisation de transformation est le même que celui pour la focalisation de base sauf quelques restrictions.

Techniques de focalisation 28

Figure 9.1: Graphe d e contrôle intraprocédural du programme

Techniques de focalisation 29

Figure 3.2: Graphe d e contrôZe intraprocéduraZ du slice

Techniques de focalisation 30

La focalisation de transformation intraprocédurale

L'ensemble des variables directement pertinentes à Vat a u niveau d'une instruction est calculé par :

Dans cet ensemble. on retrouve les mêmes sous-ensembles que pour P c ( n ) sauf quelques restrictions. En effet: nous remarquons qu'au niveau du deuxième sous-ensemble nous ne considèrerons pas les variables

xn-

Dans le cas contraire, nous obtenons les variables pertinentes a u calcul des valeurs d e

K,

et par suite les instructions qui les affectent. Ceci va à l'encontre de la définition sus-citée du dice de transformation .

Les ensembles suivant sont également similaires aus ensembles calculés dans la focalisation de base.

L'ensemble des instructions directement pertinentes est défini par :

Ce sont les instructions qui définissent les variables directement pertinent es à leurs successeurs. Cet ensemble n'englobe pas les instructions conditionnelles qui contrôlent l'exécution des instructions qui se trouvent dans T r

SE.

L'ensemble de ces instructions dénoté par TrBC est défini ainsi:

La restriction faite à ce niveau (s

4

i n

f

l ( n ) ) permet d'ignorer les instructions condi t ionnelles qui contrôlent l'exécution de la composante que l'on veut extraire. tel qu'exigé par le principe de cette technique.

L'ensemble des variables indirectement pertinentes est calculé par :

Les variables utilisées dans les instructions conditionnelles ainsi que toutes les variables qui leur sont pertinentes sont dites indirectement pertinentes à

Vaut

e t sont calculées dans l'ensemble T T

RF'

^(n):

Comme pour la focalisation de base, le slice de transformation est obtenu. après avoir atteint un point fixe pour l'ensemble des variables indirectement pertinentes: