R(cid:201)F : 2007/II2/SUJET N(cid:6)...
A-U : 2007/2008
MinistŁre de l’Enseignement SupØrieur, de la Recherche Scienti(cid:28)que et de
la Technologie
UniversitØ de La Manouba
Ecole Nationale des Sciences de l’Informatique
Rapport de Stage d’Immersion en Entreprise
rØaliser Par
Imen BENZARTI
Sujet
SPRA
Static Performance Rule Analyser
Organisme d’accueil : Adhoc ISL
Sous la direction de : Mr Marouani Slim
EncadrØ par : Mr Hmida Haithem
Adresse : Rue Madrid 5000 Monastir
TØl : (216)73 503 303 Fax : (216)73 503 303
RØsumØ
LE Le prØsent projet s’intitule " Static Performance Rule Analyzer ", il a ØtØ rØalisØ
au sein de la sociØtØ Adhoc ISL dans le cadre du stage d’insertion en entreprise.
Le travail demandØ Øtait la dØ(cid:28)nition, implØmentation et documentation des rŁgles
de validation de code source Java, l’outil dØveloppØ valide un code source de c(cid:244)tØ
performance, il est destinØ par consØquent et en premier lieu aux dØveloppeurs.
Mots clØs : performance, test de logiciel, analyseur statique de code source.
Abstract
THE The present project is named "Static Performance Rule Analyzer" ; it was
developed in Adhoc ISL company through our internship in enterprise.
The requested work was the de(cid:28)nition, documentation, implementation and test of
the performance-oriented coding rules, the developed tool validate a Java source code
from a performance view, dedicated consequently and in the (cid:28)rst place to developers.
Key words : performance, software tests, static source code analyzer.
Remerciements
Il m’est particuliŁrement agrØable, avant de prØsenter mon (cid:247)uvre, d’exprimer toute
ma gratitude envers les personnes qui, de prØs ou de loin, m’ont apportØ leur aide.
Je tiens sincŁrement (cid:224) remercier aux encadrants Mr Hmida Haithem et Mr Ben
Selem Akram pour leur contribution dans ce travail et leurs conseils prØcieux.
Table des matiŁres
Remerciements
Introduction gØnØrale
1 PrØsentation gØnØrale
1.1 PrØsentation de la sociØtØ Adhoc
. . . . . . . . . . . . . . . . . . . . .
1.2
IntØgration dans l’Øquipe Adhoc . . . . . . . . . . . . . . . . . . . . . .
1.3 Cadre gØnØrale du travail . . . . . . . . . . . . . . . . . . . . . . . . . .
2 (cid:201)tat de l’art
2.1 Le test logiciel
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 La qualitØ du code
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Les analyseurs statique de code source
. . . . . . . . . . . . . . . . . .
2.4 Critique et solution proposØs . . . . . . . . . . . . . . . . . . . . . . . .
3 Les rŁgles de codage orientØes performance
3.1 Les zones de performance
. . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Les zones de performances Java SE (J2SE) . . . . . . . . . . . .
3.1.1.1
Les entrØe/sortie . . . . . . . . . . . . . . . . . . . . .
3.1.1.2
L’objet String bu(cid:27)er . . . . . . . . . . . . . . . . . . .
iv
1
3
3
4
5
7
7
8
8
9
11
11
11
11
12
TABLE DES MATI¨RES
3.1.1.3
Les appels des mØthodes . . . . . . . . . . . . . . . . .
3.1.1.4
Les types primitifs et les types objets . . . . . . . . . .
3.1.1.5
L’accŁs aux variables instanciØes
. . . . . . . . . . . .
3.1.1.6 Class " (cid:28)nal " . . . . . . . . . . . . . . . . . . . . . . .
3.1.1.7
Les collections
. . . . . . . . . . . . . . . . . . . . . .
3.1.2
b. Les zones de performance JEE . . . . . . . . . . . . . . . . .
3.1.2.1
Les servlets . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2.2
JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.3 Les zones communes de performance . . . . . . . . . . . . . . .
3.1.3.1
Synchronisation . . . . . . . . . . . . . . . . . . . . . .
3.2 Les rŁgles de codage orientØ performance J2SE . . . . . . . . . . . . . .
3.2.1 Les rŁgles gØnØraux . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2 Les rŁgles sur les Objets . . . . . . . . . . . . . . . . . . . . . .
3.2.3 Les rŁgles des boucles . . . . . . . . . . . . . . . . . . . . . . . .
3.2.4 Les rŁgles d’exception . . . . . . . . . . . . . . . . . . . . . . . .
3.2.5 Les rŁgles des (cid:29)ux d’entrØe/sortie . . . . . . . . . . . . . . . . .
3.2.6 Les rŁgles de chaine de caractŁres (le type String) . . . . . . . .
3.2.7 Les rŁgles de collection . . . . . . . . . . . . . . . . . . . . . . .
3.2.8 Les rŁgles de synchronisation . . . . . . . . . . . . . . . . . . . .
3.3 Les rŁgles de codage orientØ performance JEE . . . . . . . . . . . . . .
3.3.1 Les rŁgles de l’API Servlet . . . . . . . . . . . . . . . . . . . . .
3.3.2 Les rŁgles JDBC . . . . . . . . . . . . . . . . . . . . . . . . . .
4 SpØci(cid:28)cation des besoins
vi
12
13
13
13
13
15
16
16
17
17
17
17
18
19
19
20
20
21
22
23
23
23
25
4.1
Introduction des besoins . . . . . . . . . . . . . . . . . . . . . . . . . .
25
TABLE DES MATI¨RES
4.2 Les besoins fonctionnels
. . . . . . . . . . . . . . . . . . . . . . . . . .
Publicité
4.3 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . .
4.4 Les cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Conception
5.1 Les choix conceptuels . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1 DØ(cid:28)nition de quelque Framework (cid:224) utiliser . . . . . . . . . . . .
5.1.1.1 Ant
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1.2 PMD . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.2 Choix de technologie . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Conception architecturale de l’application . . . . . . . . . . . . . . . .
5.2.1 L’hiØrarchie de classe dans PMD . . . . . . . . . . . . . . . . .
5.2.2 Le design pattern Visiteur . . . . . . . . . . . . . . . . . . . . .
5.2.3 Diagramme de classe de SPRA . . . . . . . . . . . . . . . . . .
6 RØalisation
6.1 La mise en oeuvre de l’outil SPRAs . . . . . . . . . . . . . . . . . . . .
6.1.1 Classi(cid:28)cation des rŁgles
. . . . . . . . . . . . . . . . . . . . . .
6.1.2 L’ajout des rŁgles . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.3 Les rŁgles de performances implØmentØes . . . . . . . . . . . . .
6.1.3.1
Les rŁgles d’exception . . . . . . . . . . . . . . . . . .
6.1.3.2
Les rŁgles de collections
. . . . . . . . . . . . . . . . .
6.1.3.3
Les rŁgles de String . . . . . . . . . . . . . . . . . . . .
6.1.3.4
Les rŁgles des boucles
. . . . . . . . . . . . . . . . . .
6.1.3.5
Les rŁgles de JDBC . . . . . . . . . . . . . . . . . . .
6.1.3.6
Les rŁgles de synchronisation . . . . . . . . . . . . . .
vii
25
26
27
28
28
28
28
29
29
30
30
30
32
35
35
36
36
36
37
39
39
41
41
45
TABLE DES MATI¨RES
6.1.3.7
Les rŁgles sur les Objet . . . . . . . . . . . . . . . . .
6.1.3.8
RŁgles gØnØrales . . . . . . . . . . . . . . . . . . . . .
6.1.3.9 RŁgles d’entrØes sortie . . . . . . . . . . . . . . . . . .
6.1.3.10 RŁgles sur les servlets
. . . . . . . . . . . . . . . . . .
6.2 Test des rŁgles implØmentØs
. . . . . . . . . . . . . . . . . . . . . . . .
6.3 Chronogramme de travail . . . . . . . . . . . . . . . . . . . . . . . . . .
Conclusion gØnØrale
Bibliographie
A Analyse de code source Java avec PMD
A.1 L’arbre syntaxique abstraite (Abstract Syntax Tree - AST . . . . . . .
A.2 Les caractØristiques d’une rŁgle avec PMD . . . . . . . . . . . . . . . .
A.3 Comment PMD analyse les codes sources . . . . . . . . . . . . . . . . .
B Les rØgles de codage classi(cid:28)Øes selon di(cid:30)cultØ
B.1 Les rŁgles classØes faciles
. . . . . . . . . . . . . . . . . . . . . . . . .
B.2 Les rŁgles classØes moyennes . . . . . . . . . . . . . . . . . . . . . . . .
B.3 Les rŁgles classØes di(cid:30)ciles . . . . . . . . . . . . . . . . . . . . . . . . .
B.4 Les rŁgles classØes trŁs di(cid:30)ciles
. . . . . . . . . . . . . . . . . . . . . .
viii
49
50
50
52
54
55
57
58
59
59
61
62
63
63
63
63
63
Liste des (cid:28)gures
1.1 Organigramme de l’entreprise Adhoc . . . . . . . . . . . . . . . . . . .
1.2 Adhoc ISL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1 L’hiØrarchie des classes de la bibliothŁque collection . . . . . . . . . . .
3.2 Les di(cid:27)Ørents niveaux d’une application J2EE [4]
. . . . . . . . . . . .
4
5
14
15
4.1 Le cas d’utilisation du dØveloppeur
. . . . . . . . . . . . . . . . . . . .
27
5.1 HØrarchie de classe dans PMD . . . . . . . . . . . . . . . . . . . . . . .
5.2 Les (cid:28)ls de la classe SimpleNode . . . . . . . . . . . . . . . . . . . . . .
5.3 Diagramme de classe du design pattern visiteur
. . . . . . . . . . . . .
5.4 Diagramme de classe de SPRA . . . . . . . . . . . . . . . . . . . . . .
6.1 Rapport genere du framework Spring . . . . . . . . . . . . . . . . . . .
6.2 Documentation d’une rŁgle . . . . . . . . . . . . . . . . . . . . . . . . .
6.3
les Øtapes de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.1 GØnØration de l’arbre syntaxique abstrait lors de la compilation . . . .
A.2 Construction d’AST d’un programme Java avec PMD designer . . . . .
A.3 Le (cid:28)chier favorite.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.4 Exemple d’un (cid:28)chier ruleset : braces.xml
. . . . . . . . . . . . . . . . .
31
32
33
33
55
55
56
60
60
61
62
LISTE DES FIGURES
B.1 Les rŁgles classØes faciles . . . . . . . . . . . . . . . . . . . . . . . . . .
B.2 Les rŁgles classØes moyennes . . . . . . . . . . . . . . . . . . . . . . . .
Publicité
B.3 Les rŁgles classØes moyennes . . . . . . . . . . . . . . . . . . . . . . . .
B.4 Les rŁgles classØes di(cid:30)ciles . . . . . . . . . . . . . . . . . . . . . . . . .
B.5 Les rŁgles classØes trŁs di(cid:30)ciles
. . . . . . . . . . . . . . . . . . . . . .
x
64
65
66
67
68
Liste des tableaux
3.1 Les rŁgles gØnØraux . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Les rŁgles sur les Objets
. . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Les rŁgles des boucles . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Les rŁgles d’exception . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5 Les rŁgles des (cid:29)ux d’entrØe/sortie . . . . . . . . . . . . . . . . . . . . .
3.6 Les rŁgles de chaine de caractŁres . . . . . . . . . . . . . . . . . . . . .
3.7 Les rŁgles de collection . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8 Les rŁgles de synchronisation . . . . . . . . . . . . . . . . . . . . . . . .
3.9 Les rŁgles de l’API Servlet . . . . . . . . . . . . . . . . . . . . . . . . .
3.10 Les rŁgles JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
18
19
20
20
21
21
22
23
24
Introduction gØnØrale
LA performance des applications devient de plus en plus le facteur le plus impor-
tant dans les solutions informatiques. En raison de son important impact sur le
dØveloppement des applications d’une part, et son aspect non fonctionnel d’autre part,
la performance reste l’attribut de qualitØ du systŁme le plus sensible qui doit Œtre me-
surØ, surveillØ et contr(cid:244)lØ conformØment aux exigences du systŁme ainsi qu’aux besoins
et aux recommandations du client.
A(cid:28)n de garantir la qualitØ du systŁme, une fois implØmentØ, le systŁme a besoin
d’Œtre surveillØ a(cid:28)n d’Øvaluer les di(cid:27)Ørents aspects de performance et de signaler n’im-
porte quel dØfaut ou faiblesse observØs.
Cependant, plusieurs outils ont ØtØ dØveloppØs pour Øvaluer la performance des ap-
plications. Ces outils rassemblent des informations pendant l’exØcution de l’application
et fournissent des indicateurs de performance qui peuvent Œtre analysØs pour identi(cid:28)er
les points faibles de la performance de l’application.
Le but de ce projet est de rØaliser un outil qui valide la performance d’un code
source Java sans recourir (cid:224) exØcuter le code c’est-(cid:224)-dire de maniŁre statique.
Le prØsent rapport synthØtise tout le travail rØalisØ dans cette perspective. Il est
organisØ en six chapitres comme suit :
(cid:21) Le premier chapitre prØsente l’organisme d’accueil (cid:224) savoir la sociØtØ Adhoc ISL.
(cid:21) Le deuxiŁme chapitre prØsente le contexte thØorique de l’application (cid:224) dØvelopper
INTRODUCTION G(cid:201)N(cid:201)RALE
2
et une Øtude de l’existant et ses limites ainsi que la solution proposØe et retenue.
(cid:21) Le troisiŁme chapitre prØsente les rŁgles de codage orientØ performance.
(cid:21) Le quatriŁme chapitre prØsente l’analyse des besoins fonctionnels et non fonction-
nels ainsi qu’une reprØsentation UML de ses spØci(cid:28)cations.
(cid:21) Le cinquiŁme chapitre est une Øtude conceptuelle de la future application.
(cid:21) Le sixiŁme chapitre est une reprØsentation de l’application rØalisØe.
Nous cl(cid:244)turons ce rapport par une conclusion qui rappelle le contexte de notre travail
ainsi que l’approche proposØe et qui ouvre les portes (cid:224) de nouvelles perspectives.
CHAPITRE1 PrØsentation gØnØrale
Le prØsent chapitre a pour objectif de situer le projet dans son cadre gØnØral (cid:224)
savoir l’entreprise accueillante, son organisation et ses principales fonctionnalitØs, ainsi
que les objectifs (cid:224) atteindre et la mØthodologie adoptØe tout au long de ce projet.
1.1 PrØsentation de la sociØtØ Adhoc
Adhoc est un centre de compØtences pour l’ingØnierie de performance, il prØsente :
(cid:21) Des services de conseil basØs sur les mØthodes d’ingØnierie pour ma(cid:238)triser la per-
formance des applications durant tout le cycle de leurs vies.
(cid:21) Des recherches et des dØveloppements consacrØs (cid:224) analyser, tester et Øvoluer la
technologie de l’ingØnierie de performance et les composants rØutilisables des ap-
plications.
Il o(cid:27)re aussi une plateforme de collaboration pour les nouvelles technologies et les
nouveaux concepts par :
(cid:21) Le partenariat avec les leaders de technologie dans le domaine de test de perfor-
mance, de la gestion des applications et de l’intØgration des mainframes.
(cid:21) La Collaboration avec des instituts de recherche et des acteurs universitaires bien
connus dans le domaine de la performance des applications.
Adhoc ISL est une sociØtØ (cid:224) responsabilitØ limitØe, totalement exportatrice, crØe (cid:224)
Monastir en janvier 2004. C’est une sociØtØ d’ingØnierie informatique spØcialisØe dans
CHAPITRE 1. PR(cid:201)SENTATION G(cid:201)N(cid:201)RALE
4
le dØveloppement et le test de performance des applications J2EE.
L’organigramme de la (cid:28)gure 1.1 ci-dessous schØmatise la position de la (cid:28)liale Adhoc
ISL dans la sociØtØ Adhoc international :
Figure 1.1 (cid:22) Organigramme de l’entreprise Adhoc
Elle a pour principal but la conception, le dØveloppement et la mise en (cid:247)uvre de
solutions informatiques ainsi que toute prestation d’Øtude, de conseil, de diagnostique
et d’audit informatique. ((cid:28)gure 1.2)
1.2 IntØgration dans l’Øquipe Adhoc
Le 16 Juin 2008, nous nous sommes rejoints (cid:224) l’Øquipe Adhoc. Suite (cid:224) une prØ-
sentation de la sociØtØ ainsi que les membres de l’Øquipe nous nous sommes installØs
dans notre bureau. A partir de ce moment-l(cid:224), nous sommes considØrØs comme l’un du
personnel d’Adhoc en termes de droits et de devoirs.
Comme tout ingØnieur de la sociØtØ, nous avons du suivre les Øtapes de dØveloppe-
ment de projet adoptØ par Adhoc et faire des tests d’Øvaluation de certaines techniques
tout en rØdigeant des documents en anglais. Ces documents sont :
(cid:21) Requirements Speci(cid:28)cation Report : ce rapport prØsente le contexte du projet et
spØci(cid:28)e les besoins fonctionnels et les besoins non fonctionnels du systŁme.
CHAPITRE 1. PR(cid:201)SENTATION G(cid:201)N(cid:201)RALE
5
Figure 1.2 (cid:22) Adhoc ISL
(cid:21) Project planning : ce document dØcrit la plani(cid:28)cation du projet (cid:224) suivre.
1.3 Cadre gØnØrale du travail
La performance est une question importante avec Java et ceci depuis que la pre-
miŁre version atteint le Web depuis quelque annØes. Rendre ces premiers programmes
s’exØcuter avec assez de rapiditØ Øtait un Ønorme dØ(cid:28) pour plusieurs dØveloppeurs.
La performance des programmes Java s’amØliore ØnormØment et n’importe quel
programme Java peut Œtre rØalisØ a(cid:28)n de s’exØcuter rapidement (cid:224) condition que le
dØveloppeur Øvite les piŁges de la performance.
Notre but est de rØaliser de outil qui teste la performance d’un programme auto-
matiquement et gØnŁrent des rapports qui listent les points faibles dans ce programme.
CHAPITRE 1. PR(cid:201)SENTATION G(cid:201)N(cid:201)RALE
6
Conclusion
Ce chapitre prØsente l’organisme d’accueil, le cadre du stage, ainsi que les objectifs (cid:224)
atteindre. En vue de suivre un avancement logique dans ce rapport, une Øtude thØorique
concernant l’Øtat de l’art fera l’objet du prochain chapitre.
CHAPITRE2 (cid:201)tat de l’art
Le dØveloppement et l’Øvolution d’un logiciel sont vus comme un processus, appelØ le
cycle de vie du logiciel. Ce cycle est composØ de plusieurs Øtapes ou phases qui commu-
niquent entre eux et dont certains Øvoluent en parallŁle. Dans chaque phase de ce cycle
existe des facteurs qui peuvent toucher (cid:224) la qualitØ et la performance de l’application.
Plus nous sommes capable de dØtecter ces anomalies le plus t(cid:244)t possible, plus notre
application est performante et la satisfaction du client est garantie. Dans ce sens est
menØ par un souci de trouver une solution qui permet de dØtecter ces problŁmes dans
la phase de dØveloppement s’intitule l’outil que nous envisageons de dØvelopper. Dans
ce chapitre nous allons prØsenter les di(cid:27)Ørentes pratiques qui permettent d’amØliorer
la qualitØ du code et Øventuellement la performance et en(cid:28)n nous allons positionner
l’outil que nous allons dØvelopper.
2.1 Le test logiciel
Tester un logiciel est le fait de dØterminer les bugs et les erreurs contenues dans
ce logiciel en le soumettant (cid:224) un jeu qui prØsentent un ensemble de donnØes et de
conditions de fonctionnement simulØes. Le but du test est d’assurer la qualitØ du code
ce qui signi(cid:28)e la recti(cid:28)cation des anomalies du logiciel, l’amØlioration de sa performance
et la vØri(cid:28)cation de son adØquation vis-(cid:224)-vis des besoins.
Distinguons plusieurs types de tests :
Tests unitaires : Ces tests sont les tests du niveau le plus bas, ils permettent de
CHAPITRE 2. (cid:201)TAT DE L’ART
8
Publicité
tester chaque module de l’application sØparØment.
[6]
Tests d’intØgration : ces tests visent (cid:224) contr(cid:244)ler les interactions entre di(cid:27)Ørents mo-
dules ou composants de l’application en les intØgrant au sein d’un sous-systŁme.
[6]
Tests du systŁme : Ces tests sont de type bo(cid:238)te noire et visent (cid:224) assurer l’acceptation
de l’application dØveloppØe par les utilisateurs.
[6]
Tests de performance : permet de cibler les problŁmes de performance et donc d’op-
timiser les composants spØci(cid:28)Øs.
[6]
Tests de recette : ils valideront le logiciel par rapport aux besoins de l’utilisateur. Ce
qui aboutira sur l’acceptation, l’acceptation conditionnelle ou le refus du produit.
[6]
2.2 La qualitØ du code
Le code doit Œtre facile (cid:224) utiliser ce qui est garantie par le choix du design pattern
adØquat avec une documentation claire, Øgalement le code ne doit pas contenir des
erreurs par consØquence un ensemble de tests doivent Œtre con(cid:231)u ainsi que les tests
unitaires qui permettent de tester chaque module ou composant de l’application sØ-
parØment. Finalement, le code doit Œtre facile maintenir puisque rarement les logiciels
sont maintenue par leurs dØveloppeurs originaux.
2.3 Les analyseurs statique de code source
L’analyse statique de code source est l’analyse d’un logiciel qui est e(cid:27)ectuØ sans
l’exØcution de programmes qui construit ce logiciel (analyse e(cid:27)ectuØe sur l’exØcution
des programmes est connu sous le nom de l’analyse dynamique).
Dans la plupart des cas, l’analyse est e(cid:27)ectuØe sur le code source et dans d’autres
cas sur une certaine forme de code objet.
CHAPITRE 2. (cid:201)TAT DE L’ART
9
Cette analyse est gØnØralement e(cid:27)ectuØe par un outil automatisØ. La sophistication
des analyses e(cid:27)ectuØes par ces outils varie de ceux qui ne considŁrent que le comporte-
ment des di(cid:27)Ørents Øtats et dØclarations, (cid:224) ceux qui comprennent le code source complet
d’un programme dans leur analyse.
Parmi ces outils distinguons :
PMD : c’est un analyseur statique de code source Java qui dØtecte des problŁmes
tels que le code dupliquØ, le code mort (non atteint), le code non optimal ... (2) Il
implØmente plus de 175 rŁgles qui assurent le respect des conventions de codage.
FindBug : C’est un outil d’analyse statique de code objet Java c’est-(cid:224)-dire les (cid:28)chiers
.class et qui permet de dØtecter certaines erreurs comme : Mauvaise implØmenta-
tion de l’interface Cloneable (cid:21) DØ(cid:28)nition d’une variable locale non utilisØe par la
suite - ...
Checkstyle : Cet outil permet d’assurer un niveau bien dØ(cid:28)ni de qualitØ de code
source. Ses vØri(cid:28)cations portent essentiellement sur la forme et ne permettent en
rien de dire qu’un programme est correct ou complet.
2.4 Critique et solution proposØs
Vue l’importance de la performance des programmes Øcrit en Java, il est important
de rØaliser des outils qui dØtectent les causes d’une mauvaise performance.
Ces outils peuvent Œtre des analyseurs de code source Java qui applique des rŁgles
orientØ performance. NØanmoins, les outils dØj(cid:224) citØs dans le paragraphe prØcØdent ne
permettent pas explicitement de dØcerner les causes possibles d’une mauvaise perfor-
mance.
Notre travail consiste (cid:224) rØaliser un outil qui doit Œtre extensible et qui permet de
signaler les parties du code source qui sont potentiellement susceptible de nuire (cid:224) la
performance des applications.
CHAPITRE 2. (cid:201)TAT DE L’ART
10
Conclusion
Ce chapitre prØsente le contexte thØorique du projet de stage d’ØtØ qui se base
essentiellement sur la gestion des anomalies de performance des codes source Java.
Cette Øtude nous a permis de dØgager une solution contribuant dans l’amØlioration
de l’Øtat des analyseurs statiques de code source a(cid:28)n qu’il s’adapte au problŁme de
performance.
CHAPITRE3 Les rŁgles de codage
orientØes performance
Il y a une perception gØnØrale que les programmes Java sont lents, mais avec la
progression de la machine virtuelle Java et des outils de dØveloppement une applica-
tion Java (ou applet, servlet, etc) doit s’exØcuter (cid:224) la rapiditØ attendu. Avec une bonne
conception et en suivant de bonnes pratiques de codage, les applications peuvent gØ-
nØralement s’exØcuter assez vite. [5]
Plusieurs zones dans un programme Java/JEE sont sensibles de point de vue perfor-
mance, Plusieurs ce des zones peuvent Œtre rØglØe et corrigØe au prØalable pour fournir
vers la (cid:28)n une application performante qui suscite la satisfaction du client
3.1 Les zones de performance
3.1.1 Les zones de performances Java SE (J2SE)
3.1.1.1 Les entrØe/sortie
Les entØes/sorties sont particuliŁrement couteuses si elles sont mal utilisØes. En
e(cid:27)et, il existe une variØtØ de techniques pour l’amØlioration de la performance des
entrØe/sortie en Java. La plupart de ces techniques s’articulent autour de rØglage des
(cid:28)chiers d’entrØe/sortie disque, mais certaines sont applicables au entrØe/ sortie rØseau
ainsi que les fenŒtres de sortie.
CHAPITRE 3. LES R¨GLES DE CODAGE ORIENT(cid:201)ES PERFORMANCE
12
3.1.1.2 L’objet String bu(cid:27)er
L’utilisation de " += " sur le type String est trŁs coßteux, la raison est que les String
ne sont pas modi(cid:28)Øe aprŁs leurs crØation. Pour ajouter (cid:224) une chaine de caractŁre vous
devez la copier (cid:224) un Objet StringBu(cid:27)er et concatØner (cid:224) elle une autre chaine et puis
la convertir en String. StringBu(cid:27)ers sont utilisØs pour e(cid:27)ectuer des opØrations sur les
chaines, comme "+" et "+=".
3.1.1.3 Les appels des mØthodes
Le coßt de performance ØlevØ associØ aux appels de mØthode est causØ par plusieurs
e(cid:27)ets, citons le temps nØcessaire (cid:224) la mise en place de la pile d’appels et le transfert de
contr(cid:244)le a la mØthode.
Dans Java le cause principale du coßt ØlŁve de l’appel de mØthode est que ces dernier
sont par dØfaut virtuels, la mØthode rØel appelØ est dØterminØ au cours de l’exØcution
en considØrant le type de l’objet utilisØ.
Par exemple, l’objet de type Objet, duquel tous les classes dØrivent, possŁde une
mØthode appelØ hashCode(), une classe qui hØrite de la classe Objet dØ(cid:28)nie aussi la
mØthode hashCode() . Donc si nous avons un programme qui rØfØrence un objet de
type Objet, oø nous avons un appel (cid:224) la mØthode hashCode() :
public void f(Object p)
{
int h = p.hashCode() ;
}
La version appelØe de hashCode() dØpend de p : s’il est de type Objet ou d’un type
qui dØrivent de Objet. [4]
Le mot clØ " (cid:28)nale " peut accorder une optimisation importante puisqu’elle interdit
la modi(cid:28)cation de mØthodes hØritØes par des classes dØrivantes.
CHAPITRE 3. LES R¨GLES DE CODAGE ORIENT(cid:201)ES PERFORMANCE
13
Le coßt de performance des appels des mØthodes devient plus ØlevØ si la mØthode
est appelØe au sein d’une boucle plusieurs fois.
3.1.1.4 Les types primitifs et les types objets
Les types primitifs (int, double, (cid:29)oat, etc.) ne sont pas des types classe ; ils ne
possŁdent pas cette propriØtØ. Mais il y a des types classes qui peuvent prØsenter ces
types primitifs et les introduire dans la hiØrarchie Objet.
Les types objet possŁdent l’avantage de traiter les types primitifs comme des Objets.
Mais ils ont un coßt de performance trŁs important aux niveaux d’espace mØmoire et
temps d’exØcution.
3.1.1.5 L’accŁs aux variables instanciØes
L’accŁs aux variable dans un programme peut Œtre coßteux en utilisant les getters
et les setters surtout si la variable est accØdØ plusieurs fois dans une boucle.
La solution pour rØduire le coßt consiste (cid:224) crØer des copies locales pour ces variables.
3.1.1.6 Class " (cid:28)nal "
Les classes qui utilisent le mot clØ " (cid:28)nal " ne peuvent hØriter d’une classe ou Œtre
sous classØ, ceci apporte un avantage a(cid:28)n d’interdire l’introduction d’un comportement
anormale dans cette classe.
Les classes " (cid:28)nal " amØliorent la performance puisque toutes ces mØthodes sont "
(cid:28)nal " aussi.
3.1.1.7 Les collections
La plateforme Java fournis quelques structures de donnØe de base sous forme des
classes java.util.Vector et java.util.Hashtable. Bien qu’ils fussent utilisØs avec succŁs par
plusieurs dØveloppeurs, ces classes ont de nombreux problŁmes liØs (cid:224) la performance.
CHAPITRE 3. LES R¨GLES DE CODAGE ORIENT(cid:201)ES PERFORMANCE
14
A chaque version de Java des autres structures sont ajoutØe avec des algorithmes
de haute performance.
Une collection est un objet qui regroupe plusieurs ØlØments. Elles sont utilisØes
pour enregistrer, rechercher et manipuler des donnØes. Elles sont aussi utiliser pour
transmettre des donnØes d’une mØthode (cid:224) une autre.
En fournissant une bonne performance et haute qualitØ d’implØmentation des struc-
tures de donnØes utiles et des algorithmes, les collections aident (cid:224) amØliorer la perfor-
Publicité
mance du logiciel (cid:224) dØvelopper.
La bibliothŁque des collections est basØe sur six interfaces de collection et fournit
l’implØmentation de chacune de ces interfaces et les algorithmes qui les manipulent.
La (cid:28)gure 3.1 montre l’hiØrarchie des interfaces et des classes qui construisent le
noyau de la bibliothŁque.
Figure 3.1 (cid:22) L’hiØrarchie des classes de la bibliothŁque collection
Chacune de ces interfaces est plus adØquate pour une t(cid:226)che bien dØterminØe. A(cid:28)n
d’atteindre la vitesse d’exØcution minimale et l’utilisation optimale de la mØmoire, le
dØveloppeur doit utiliser l’implØmentation la plus adØquate pour son application.
CHAPITRE 3. LES R¨GLES DE CODAGE ORIENT(cid:201)ES PERFORMANCE
15
3.1.2 b. Les zones de performance JEE
JEE utilise un model distribuØe multi-tiers. Ce modŁle inclut gØnØralement un ni-
veau client, un niveau de contr(cid:244)le et le niveau system d’information de l’entreprise
(Enterprise Information System EIS). Le niveau client peut Œtre une ou plusieurs ap-
plications ou un navigateur. La plateforme JEE se trouve au niveau contr(cid:244)le au milieu
et consiste (cid:224) un serveur web et un serveur de EJB (Entreprise Java Bean). Nous pou-
vons avoir d’autres niveaux au milieu. Le troisiŁme niveau EIS composØ des applications
existantes, des (cid:28)chiers et des bases de donnØes [4]. ( 3.2)
Figure 3.2 (cid:22) Les di(cid:27)Ørents niveaux d’une application J2EE [4]
Pour la conservation des donnØes, la plateforme JEE nØcessite une base de donnØes
accessible (cid:224) travers JDBC, SQLJ, or JDO API.
CHAPITRE 3. LES R¨GLES DE CODAGE ORIENT(cid:201)ES PERFORMANCE
16
La performance de l’application est importante dans chacun de ces niveaux. Nous
nous intØressons particuliŁrement (cid:224) deux zones de performance : Les Servlets (niveau
contr(cid:244)le), JDBC (EIS)
3.1.2.1 Les servlets
Servlet prØsente une extension du serveur Http. Elle prend une requŒte http comme
entrØe et renvois une rØponse Http au client comme sortie.
L’API Servlet fournis deux packages : javax.servlet et javax.http.servlet. Ces deux
packages contiennent des interfaces et des classes qui manipulent les fonctionnalitØs http
a(cid:28)n de permettre au dØveloppeur d’Øcrire une Servlet en Java qui re(cid:231)oit des requŒte
http du client et lui envois des rØponses http. Le client est dans la plupart des cas un
navigateur.
La Servlet est chargØ en mØmoire par le moteur de Servlet elle fait appel a la
mØthode init() (cid:224) la premier requŒte puis seulement la mØthode service() est appelØ
pour les requŒte d’aprŁs. A la (cid:28)n la mØthode destroy() est appelØ lorsque la Servlet est
enlevØ par le moteur de Servlet.
3.1.2.2 JDBC
JDBC est utilisØ pour accØder (cid:224) des bases de donnØes relationnelles. La connexion
JDBC supporte l’exØcution et la crØation des requŒtes.
Ces requŒte peuvent Œtre des requŒte de mise (cid:224) jour pour SQL par exemple
CREATE, INSERT, UPDATE et DELETE ou des requŒtes de lecture de donnØes
ainsi que SELECT. En outre les appels des procØdures enregistrØes dans la base. Une
requŒte est confondue avec l’un des trois types suivant :
Statement : pour les requŒtes qui ne s’exØcutent pas plusieurs fois.
PreparedStatement : pour les requŒtes qui sont exØcutØ plusieurs fois.
CallableStatement : pour l’exØcution des procØdures enregistrØes dans la base.
[4]
CHAPITRE 3. LES R¨GLES DE CODAGE ORIENT(cid:201)ES PERFORMANCE
17
3.1.3 Les zones communes de performance
3.1.3.1 Synchronisation
Dans notre contexte, la synchronisation signi(cid:28)e l’exclusion mutuelle ; le block syn-
chronisØ doit Œtre atomique c’est-(cid:224)-dire accessible par un seule processus. La mauvaise
utilisation des synchronisations infecte dans plusieurs situations la performance des
applications car elles conduisent (cid:224) des blocages et (cid:224) des mauvaises utilisations des
ressources critiques de l’application.
Nous avons dØ(cid:28)nie dans cette partie les zones dans un programme Java/JEE sensible
de c(cid:244)tØ performance et qui peuvent, si nous ne respectons pas les rŁgles de codage,
conduire (cid:224) des temps d’exØcution Ønorme et un gaspillage de la mØmoire. Dans la
prochaine partie nous listons les rŁgles de codage orientØ performance.
3.2 Les rŁgles de codage orientØ performance J2SE
3.2.1 Les rŁgles gØnØraux
RØgle Description
GR01 Ne pas appeler la mŒme mØthode dans un test conditionnel
GR02 Ne pas instancier des variables inutilisables
GR03 Ne pas utiliser des appels aux mØthodes pour vØri(cid:28)er la condition
d’arrŒt de boucle.
CHAPITRE 3. LES R¨GLES DE CODAGE ORIENT(cid:201)ES PERFORMANCE
18
GR04 Utiliser des variables statiques pour les attributs qui ont besoin
d’Œtre a(cid:27)ectØ une seule fois.
GR05 Ne pas accØder a des variables privØs de la classe interne depuis la
classe contenant.
GR06 Rendre nulle les rØfØrences qui ne sont plus utilisable dans le pro-
gramme.
GR07 Utiliser des variables locaux au lieu des variables statiques (de
classe)
GR08 Utiliser des opØrateurs composØ, tel que n=+4, au lieu de opØrateur
primitifs, tel que n=n+4, car elles gØnŁrent moins de byte code.
GR09 Utiliser le design pattern lazy-loading pour les objets dØpendants
(ce design pattern vise (cid:224) initialiser des ØlØments "(cid:224) la demande")
GR10 Utiliser s’il est possible des mØthodes statiques et privØs et des
classes " (cid:28)nal "
Tableau 3.1 (cid:22) Les rŁgles gØnØraux
3.2.2 Les rŁgles sur les Objets
RŁgle Description
OR01 Ne pas crØer des objets dans une boucle
OR02 Utiliser des chaines de caractŁres littØral au lieu de crØer les crØer
sous forme d’objet (avec ’new ’) si le contenue est le mŒme.
OR03 Utiliser des types primitifs au lieu des types Objet.
OR04 Seulement si c’est inØvitable, utiliser des variables locaux au lieu
des variables de classe.
OR05 Garder des constructeurs simples et l’hiØrarchie d’hØritage si pos-
sible moins profonde.
OR06 (cid:201)viter d’initialiser les variables plusieurs fois.
Tableau 3.2 (cid:22) Les rŁgles sur les Objets
CHAPITRE 3. LES R¨GLES DE CODAGE ORIENT(cid:201)ES PERFORMANCE
19
3.2.3 Les rŁgles des boucles
RŁgle
description
LR01 Utiliser les entiers comme index de boucle.
LR02 Utiliser System.arraycopy()pour copier les tableaux.
LR03
(cid:201)viter l’appel de mØthode dans une boucle.
LR04 Comparer la condition de (cid:28)n de boucle avec zØro.
LR05
(cid:201)viter l’utilisation des mØthodes pour vØri(cid:28)er la condition de (cid:28)n de
boucle.
LR06
Lors de l’utilisation des opØrateurs logiques placer l’expression qui
est susceptible d’Øvaluer fausse sur l’extrŒme gauche si l’expression
contient & &.
LR07
Lors de l’utilisation des opØrateurs logiques placer l’expression qui
est susceptible d’Øvaluer vrai sur l’extrŒme gauche si l’expression
contient ||.
LR08 Ne pas traiter des exceptions dans une boucle.
Tableau 3.3 (cid:22) Les rŁgles des boucles
3.2.4 Les rŁgles d’exception
RŁgle description
ER01 SpØci(cid:28)ez le type d’exceptions lorsque vous manipulez l’exception
dans le bloc catch.
ER02 SpØci(cid:28)ez le type d’exceptions lorsque vous lancez l’exception dans
la clause throws.
ER03 Ne pas utiliser les exceptions pour contr(cid:244)ler le (cid:29)ux du programme.
ER04 Utilisez toujours le bloc (cid:28)nally pour libØrer les ressources nØcessaires
pour prØvenir les fuites de ressources.
CHAPITRE 3. LES R¨GLES DE CODAGE ORIENT(cid:201)ES PERFORMANCE
20
ER05 Traiter l’exception localement si possible.
Tableau 3.4 (cid:22) Les rŁgles d’exception
3.2.5 Les rŁgles des (cid:29)ux d’entrØe/sortie
RŁgle Description
IOR01 (cid:201)viter les opØrations des informations sur les (cid:28)chier tel que
File.length() , puisqu’elle nØcessite un appel systŁme.
IOR02 Utiliser le mot clØ "transient" pour les variables inutiles qui n’ont
pas besoin d’Œtre lu/Øcrites dans les (cid:29)ux.
Publicité
IOR03 (cid:201)vitez la lecture et l’Øcriture des donnØes en utilisant le...