Conception et Mise en Œuvre d`un Outil Interactif d`Aide à la

Université de la Manouba
École Supérieure de Commerce de Tunis
MEMOIRE DE FIN D’ÉTUDES
Présenté en vue de l’obtention de :
La Maîtrise en Informatique Appliquée à la Gestion des Entreprises
Sujet :
Conception et Mise en Œuvre d’un Outil Interactif d’Aide à
la Maintenance des Applications Web : WebAnalyser
Élaboré par :
Mr Yazid Erman
Encadré par :
Mme Sélima Besbes Essanaa (ESC)
Année Universitaire : 2006 - 2007
1
Remerciements
Je tiens à remercier ALLAH qui m’a accordé ses bienfaits et
ses générosités, je remercie sa majesté pour les personnes par les
quelles j’étais soutenu tout au long de ma vie :
J’adresse mes remerciements les plus distingués à mon
encadreur Mme Sélima Besbes Essanaa qui m’a proposé ce sujet. En
plus de ses précieux conseils, elle a supporté avec patience tout le
labeur durant la correction de mon rapport.
J’adresse, en signe de reconnaissance, mes plus vifs
remerciements pour l’extrême sympathie à Mme Chiraz Latiri, qui ne
m’a enseigné seulement comment programmer, mais aussi comment
être au service des autres, je n’oublierai jamais ses efforts pour
m’avoir aidé à m’adapter à la formation en français dés le début.
Mes remerciements s’adressent aussi à tous les enseignants de
l’ESC qui ont contribué à ma formation.
Yazid Erman
2
Dédicace
Je dédie ce travail à …
Samih
Haifa,
Fatmeh, Laiali, Boudour, Sedra, Yazan,
Mohammed, Yassine, Fadi, Ghassan, hamdan,
Ahmed.Q, Med.J, adey,Wael,ayoub, Shadi,
Anas, ahmed.H, Med.A, Ayed,
Nabil.S, Med.M, Nabil.R,
Abdallah, Malak,
Tasneem,
Ines
.
J’espère qu’ils trouveront dans ce travail l’expression de ma gratitude,
de mon amour, de ma reconnaissance et de mon profond attachement.
Yazid Erman
3
4
Table des matières
Introduction...................................................................................................................... 7
i. Description du Contexte.................................................................................................... 10
ii. Description de la problématique ..................................................................................... 13
iii. Présentation de la contribution ...................................................................................... 13
Chapitre 1. Catégorisation des applications Web ......................................................... 15
1.1. Introduction.................................................................................................................... 15
1.2. Application Web … ou Site Web ?............................................................................... 16
1.3. L’architecture d’une applications Web ....................................................................... 19
1.4. Les Catégories d’applications basées sur le Web........................................................ 20
1.5. Les composants Web ..................................................................................................... 22
1.5.1. Pages Serveur / Pages Client .................................................................................................. 24
1.5.2. Pages Statiques / Pages Actives / Pages dynamiques ............................................................. 24
1.6. HTML ............................................................................................................................. 25
Chapitre 2. État de l’Art................................................................................................. 27
2.1. Le Modèle proposé par Ricca et Tonella : [Ric 00a ].................................................. 27
2.2. Le Modèle proposé par Conallen [Con 00].................................................................. 28
3.3. Le Modèle proposé par Tramontana : [Tra 05].......................................................... 30
Chapitre 3. Proposition.................................................................................................. 32
3.1. Étude des composants Web........................................................................................... 32
3.1.1. Les pages Statiques : .............................................................................................................. 32
3.1.1.1-les relations d’inclusion :................................................................................................. 35
3.1.1.2-les relations d’utilisation : ............................................................................................... 36
3.1.2. Les Pages Actives (Client-Side) :........................................................................................... 37
3.1.3 Les pages dynamiques (Server Side) :..................................................................................... 39
3.2. Le Modèle Proposé ........................................................................................................ 40
3.3. Le logiciel........................................................................................................................ 46
3.3.1. Description générale............................................................................................................... 46
3.3.2. Les alternatives … et choix .................................................................................................... 47
3.3.2.1. Le langage de programmation utilisé.............................................................................. 48
3.3.2.2. Le parseur ....................................................................................................................... 48
3.3.2.3. Stockage et sauvegarde de la base de données ............................................................... 52
3.3.2.4. Persistance des données.................................................................................................. 53
3.3.2.5. Cycle de vie .................................................................................................................... 57
3.3.3. Le Dossier de Conception de WebAnalyser ........................................................................... 58
3.3.3.1 Etude de faisabilité .......................................................................................................... 59
3.3.3.2. Identification des besoins et spécification des fonctionnalités : ..................................... 60
3.3.3.3. Phases d’analyse ............................................................................................................. 67
3.3.3.4. Phase de conception : ..................................................................................................... 70
3.3.3.5. Phase d’implémentation.................................................................................................. 76
Conclusion...................................................................................................................... 79
Bibliographie.................................................................................................................. 82
Table des figures
5
Figure 1. Classification des applications Web d’après [Mec 99] et [Con 00] ________ 18
Figure 2. La structure générale d’une application Web_________________________ 23
Figure 3. Le Modèle proposé par Ricca et Tonella : [Ric 00a] ___________________ 27
Figure 4. Le Modèle proposé par Conallen [Con 00] __________________________ 28
Figure 5. le Modèle proposé par Tramontana [Tra 05 ]_________________________ 30
Figure 6. La structure d'une page HTML ___________________________________ 35
Figure 7. La relation d'inclusion __________________________________________ 36
Figure 8. La relation d'utilisation__________________________________________ 37
Figure 9. Le Modele Global Retenu _______________________________________ 45
Figure 10. L'architecture du logiciel "Web Analyser" _________________________ 46
Figure 11. La classe Lexer_______________________________________________ 49
Figure 12. La classe Parser ______________________________________________ 50
Figure 13. La classe HTMLEditorKit ______________________________________ 50
Figure 14. L'architecture de Hibernate _____________________________________ 55
Figure 15. L'architecture interne de l’EJBs __________________________________ 56
Figure 16.Le code d'une page HTML ______________________________________ 59
Figure 17. Le Modèle des cas d'utilisation __________________________________ 62
Figure 18. Un Modèle Générique de Séquences ______________________________ 64
Figure 19. La fenêtre principale du WebAnalyser_____________________________ 65
Figure 20. La fenêtre de personnalisation des balises à extraire par WebAnalyser ___ 66
Figure 21. Le Modèle du Domaine ________________________________________ 67
Figure 22. Diagramme de Classes Entités ___________________________________ 68
Figure 23. Diagramme d’Activités de Navigation_____________________________ 70
Figure 24. Diagramme de Séquences : choisir entre les projets créés précédemment _ 72
Figure 25. Diagramme de Séquences : spécifier le site et lancer le « parsing » ______ 73
Figure 26. Diagramme de sequences: fixer les options spécifiques à chaque projet___ 74
Figure 27. Diagramme de classes de conception ______________________________ 75
Figure 28. Diagramme de classes de conception détaillé _______________________ 75
6
Table des Tableaux
table 1 : Les composants Web..................................................................................................... 23
table 2: Les composants principaux du HTML ........................................................................... 32
table 3: Les composants actifs des pages Web............................................................................ 38
table 4: Les composants Web dynamiques.................................................................................. 39
table 5 : Comparaison MySq l 5.0 X Postgre 8.1...................................................................... 52
table 6 :Comparaison JDBC X Hibernate X EJBs...................................................................... 54
7
Introduction
La survie de toute entreprise est étroitement liée à son existence sur le Web. Ceci est
particulièrement vrai pour les multinationales. Ces entreprises ont dépassé les frontières
de leurs pays d’origine non pas grâce à des « buildings géants », mais plutôt grâce à une
présence virtuelle allant au devant du client, à chaque demeure et à chaque bureau, et ce
à travers l’efficacité et la rentabilité de la technologie Web.
La dernière décennie a assisté à une explosion du nombre d’applications basées sur
le Web. Malheureusement, la technologie Web évolue à un tel rythme qu’une
application Web est très vite obsolète. Or, l’état de l’art révèle une panoplie aussi riche
que diverse de travaux ciblés sur la conception et le développement d’applications Web.
En revanche, il existe un réel besoin en outils et techniques qui assistent le développeur
lors de la maintenance et l’évolution de ces dernières.
En effet, malgré les tentatives, les outils disponibles ne répondent que partiellement
aux attentes des développeurs. Plusieurs facteurs sont à l’origine de ce constat. Le plus
important étant, la complexité et l’effort nécessaires à la compréhension d'un système
avant toute intervention en vue de le corriger ou de le faire évoluer par de nouveaux
besoins.
On propose dans le cadre de ce mémoire un outil, appelé WebAnalyser dont le
principal objectif est d’exhiber l’architecture interne d’une application Web en
8
dévoilant d’une part ses différentes composantes et d’autre part, les liens qui existent
entre elles, afin d’en faciliter la compréhension.
Cet outil s’inscrit dans le cadre d’un projet de rétro-conception d’applications Web
appelé RetroWeb. RetroWeb est une démarche qui a été proposée par Madame Sélima
Besbes Essanaa, au sein de l’équipe ISID (Ingénierie des Systèmes d’Information
Décisionnels) du laboratoire CEDRIC (Centre d’études et de Recherche en
Informatique du Cnam) du CNAM (Conservatoire National des Arts et Métiers) à Paris,
et ce dans le cadre de sa thèse de doctorat, qui sera publiée dans les mois à venir.
RetroWeb est une solution pour la rétro-conception de sites Web peu (ou pas)
documentés. Elle permet de déduire, à partir du code HTML d'un site Web, une
description conceptuelle de son contenu informatif qui serait utile pour la restructuration
du site, pour son évolution ou pour son intégration à un autre site Web. Or, avant tout
processus de rétro-conception, le passage par une phase de compréhension de
l’application existante est indispensable. WebAnalyser intervient en amont de
RetroWeb pour assister le rétro-concepteur (ou plus généralement le développeur) dans
la compréhension de l’architecture interne d’une application Web.
Pour mener à bien ce travail, nous avons commencé par une étude approfondie des
composantes qui peuvent intervenir dans la construction d’une application Web. A notre
surprise, cette tâche s’est révélée tout de suite très fastidieuse, à cause notamment de la
richesse et la grande variété de composantes qui peuvent être impliquées dans le
développement d’une application Web ; dés lors que celle-ci dépasse les simples pages
statiques.
Notre étude de l’existant nous a par ailleurs, révélé l’existence de plusieurs travaux
qui ont abordé cette problématique à un niveau conceptuel. Nous les avons étudiés,
comparés pour enfin synthétiser le résultat de nos investigations dans un modèle qui
donne la description d’une application Web générique. Chaque application Web à traiter
devient par conséquent, une instance de ce modèle.
Le système WebAnalyser est basé sur ce modèle. Dés le départ, nous étions
conscients que les contraintes de délais ne nous permettraient pas de produire un
système qui prendrait en charge absolument toutes les catégories de composantes. Nous
étions donc obligés de choisir entre deux alternatives : soit survoler superficiellement
toutes les composantes ; soit au contraire choisir les composantes les plus répandues et
les plus usuelles dans le développement des applications Web et les approfondir
9
convenablement. Nous avons naturellement opté pour la seconde alternative et dés le
départ, nous avons conçu un système facile à faire évoluer pour qu’il prenne en charge
n’importe quel nouveau composant.
Les paragraphes qui suivent décrivent et détaillent le cadre général de ce travail
ainsi que la problématique abordée.
i. Description du Contexte
Depuis sa première apparition le World Wide Web (WWW) a fondamentalement
transformé notre vie. Cette révolution a façonné notre société et continuera à
l’influencer durant les prochaines décennies. Chaque jour qui passe est une
confirmation de la place que le Web est en train d’occuper, aux côtés des autres grandes
inventions de ce siècle et qui ont été de véritables challenges pour les générations
précédentes.
L’interface simple et diffusée en masse du browser a ouvert la porte au
développement de plusieurs nouvelles applications distribuées. En 1994, les pages Web
étaient alors simples, statiques et reliées entre elles. Elles permettaient un accès facile à
l’information, à la portée de tous, partout dans le monde. Plus tard, de nouvelles
technologies telles que Java, ont vu le jour et ont été utilisées pour décorer les pages
Web. Elles se sont alors ornées d’effets spéciaux : images flashantes, fenêtres dansantes,
etc.
Heureusement, le monde a bien compris l’énorme potentiel que peut offrir le Web,
et des applications plus importantes, qui exploitent ces potentiels ont vu le jour. Les
organisations se sont intéressées à ces technologies et ont compris les enjeux
économiques d’une présence rapide sur le Web. Elles ont alors commencé à développer
des applications Web qui livrent leurs service jusqu’à chez leurs clients dans le monde
entier, abolissant ainsi les frontières et enregistrant de fameuses plus-values. L’ère ou le
Web était considéré comme une simple plateforme permettant le partage et la diffusion
de l’information est révolue pour céder la place à une ère de concrétisation, où le Web
est un outil sophistiqué de commerce et de transactions. L’ingénierie du logiciel est au
cœur même de cette révolution.
Une application Web est une application interactive dans laquelle l’interface
utilisateur est constituée par un ensemble de pages Web [Con 00]. Ce type
10
d’applications est une composante du Système d’Information (SI) d’une organisation.
On parle alors de systèmes d’information basés sur le Web ou Systèmes d’Information
Web (SIW) [Tak 97] [Isa 98a].
Tout comme un SI traditionnel, un SIW est un ensemble constitué de ressources
humaines et de moyens techniques, de règles de fonctionnement, de données et de
procédés pour acquérir, mémoriser, transformer, rechercher, communiquer et restituer
ces données [Rol 88]. Dans ce cadre, le Web constitue un support pour la mise en
oeuvre de ces systèmes. Il convient donc de noter qu’un SIW est d’abord un SI
traditionnel et ensuite un système basé sur le Web [Den 98].
Dans une application Web, l’information n’est pas seulement de type texte, mais
également de type image, son, vidéo ou multimédia. En plus, elle est présentée selon
une approche hypermédia, qui reprend les principes de l’organisation non linéaires,
accessible de façon explorative par de multiples chemins de navigation, au moyen de
connexions explicites entre des éléments d’information. Cette organisation non linéaire
est un élément déterminant de l’approche SIW.
La plupart du temps, les techniques utilisées par les développeurs des applications
Web sont similaires à ceux ad hoc utilisées par leurs prédécesseurs dans les années 60 et
70,
ignorant les principes de conception disciplinés, acquis durant des années
d’expérience.
Une étude récente, réalisée par Lang et Fitzgerald [Lan 05] sur le développement de
projets basés sur le Web, a révélé que dans 98 % des cas, les équipes de développement
rencontrent des problèmes majeurs pour faire face aux conditions instables et
changeantes de l’environnement Web et que dans 86% des cas ils ont du mal à s’adapter
au « Web Time » et à la pression qui le caractérise. Les développeurs d’applications
Web se défendent et se justifient en invoquant diverses raisons :
-
Le temps consacré au développement d’une application Web est extrêmement
concis : alors que le développement des applications traditionnelles nécessite des
mois, celui des applications Web nécessite des semaines voir même des jours. Ce
phénomène, souvent appelé « Web Speed » ou vitesse du Web, rétrécit
considérablement les délais. Souvent pris au dépourvu, les développeurs
d’applications Web optent pour une approche ad hoc, plus simple en apparence,
mais dont les retombés sont néfastes, dés lors que la taille de l’application devient
11
importante, et que les conséquences d’une modification du code de l’application,
deviennent imprévisibles.
-
La rapidité de l’évolution de l’environnement d’une application Web : les
applications Web deviennent obsolètes aussitôt livrées. Ce n’est qu’après avoir
été exploitées pendant les dix ou quinze dernières années, que les applications
traditionnelles peuvent être considérées comme dépassées. Une application Web,
quant à elle, elle l’est seulement après six ou sept mois d’exploitation.
-
Les attentes des utilisateurs des applications Web : Le processus de
développement qui conduit à l’application Web comporte des phases de test et de
vérification très rigoureuses, ciblées principalement sur l’interface utilisateur. Car
dans le contexte du Web, tout gravite autour de leur satisfaction. Pour une
application de commerce électronique, par exemple, la tolérance aux erreurs, frôle
le seuil zéro.
-
La rotation du personnel : La communauté Web a un taux élevé de rotation du
personnel, la durée moyenne de recrutement étant de d’un peu plus d’un an [Kon
00]. Très souvent, les développeurs initiaux de l’application Web ne font plus
partie de l’équipe informatique qui la maintient.
Il est clair, que dans ces conditions d’exploitation, la maintenance et l’évolution
d’une application Web sont des tâches très complexes, qui peuvent dégénérer
rapidement. Pour maîtriser les conséquences d’une intervention sur le code, la
compréhension de la structure de l’application et des interactions qui existent entre ses
différents composants est une tâche inévitable. Or le coût et le temps consacrés à la
compréhension augmentent dramatiquement avec la taille et la complexité de
l’application.
Certes, pour concevoir et développer des applications Web, les développeurs auront
besoin d’outils et de méthodes qui couvrent tout le cycle de vie d’une application et qui
offrent un support méthodologique à chacune de ses phases. Par ailleurs, comme le
domaine du Web arrive à maturité ils auront également besoin de méthodes et d’outils
qui les aident à analyser et comprendre la structure et l’architecture des applications
existantes.
12
ii. Description de la problématique
Comme nous venons de le voir, dans le contexte du Web, les évolutions sont plus
rapides, les mises à jour sont plus fréquentes, les délais sont rétrécis, les technologies
impliquées sont plus diversifiées et plus complexes et le taux de rotation du personnel
est très élevé. Dans ces conditions, les fréquentes interventions à caractère urgent sur le
code de l’application, de façon ad hoc entraînent inévitablement une détérioration de la
structure de navigation de l’application, de son contenu informatif, ainsi qu’une
dégradation de sa documentation.
Ces constats sont confirmés par un récent sondage, réalisé par le cutter consortium
[Cut 00], sur les projets de développement d’applications Web. Ce sondage a révélé que
84% des applications ne correspondent pas aux besoins du métier, que 52% d’entre elles
sont de qualité médiocre et que 53% ne couvrent pas les fonctionnalités pour lesquelles
elles ont été conçues. Dans de tels cas apparaît la difficulté de faire évoluer ces
applications
Durant les dernières décennies, la communauté informatique a pris conscience que
le succès ou l’échec de tout processus d’évolution ou de modernisation, de leurs
systèmes informatiques, est conditionné par la qualité de la compréhension qui en est
faite. Une bonne compréhension du code minimiserait le risque d’erreurs et faciliterait
considérablement des tâches comme la maintenance corrective, la maintenance
évolutive, ou simplement la mise à jour de la documentation.
iii. Présentation de la contribution
« On fait œuvre scientifique en citant les travaux antérieurs … »
Pour assister le développeur dans la compréhension d’applications Web existantes,
nous avons conçu et développé un outil appelé « WebAnalyser ». Nous étions
préoccupés par deux aspects :
-
Le premier est en rapport avec la façon dont le résultat sera rendu à l’utilisateur.
Notre contrainte était que ce dernier se doit d’améliorer réellement la
13
compréhension de l’application et éviter ainsi de se retrouver dans une situation
où le code est plus intelligible que la représentation que nous allons en faire. Or le
processus de compréhension de n’importe quelle application est supporté par la
description mentale qui en est faite. Notre outil déduit à partir d’une application
Web une description sous forme d’une arborescence dans laquelle les feuilles sont
les différentes composantes de l’application. L’architecture de l’application est
ensuite enrichie en exhibant deux catégories de liens : des liens d’inclusion et des
liens d’utilisation.
-
La seconde préoccupation concerne la robustesse de l’outil. Ce dernier doit être
paramétrable, et surtout facile à faire évoluer en vue de tenir compte de nouveaux
types de composantes. Pour cela, nous avons proposé un modèle qui donne la
description d’une application Web générique sur lequel s’appuie WebAnalyser.
Chaque application Web à traiter devient par conséquent, une instance de ce
modèle. Grâce à cette approche une même application peut générer différentes
descriptions.
Nous avons structuré notre rapport comme suit :
Le premier chapitre est dédié à la description des catégories d’applications Web
existantes.
Le second chapitre présente l’état de l’art sur notre problématique.
Le chapitre 3 présente notre contribution. Il est divisé en deux sections. La première
présente notre solution conceptuelle. Nous y décrivons notamment, les composants pris
en charge par notre outil ainsi que le modèle qui les supporte. La seconde section est
consacrée à la description de la réalisation de WebAnalyser. Dans cette dernière section
nous décrivons notamment l’architecture de cet outil, les choix techniques pris en
compte et enfin, le cycle de développement suivi.
Enfin, nous concluons ce rapport en proposant des améliorations et des perspectives
pour WebAnalyser.
Nous espérons, à travers ce rapport, réussir à susciter votre intérêt pour ce travail.
14
Chapitre 1. Catégorisation des applications Web
(Knowing the territory
is mandatory.)
1.1. Introduction
La dernière décennie a vu apparaître, une vague de nouvelles technologies pour
publier et répandre des données sur le Web. Cette situation a entraîné de nouvelles
catégories d’applications. Beaucoup d’entre elles, ont été initialement crées à l’image
d’une plate-forme de partage de documents, pour répondre au besoin relativement
modeste de dissémination passive des informations. Son évolution en vue de répondre à
des besoins plus agressifs, tel que le commerce électronique ou la collaboration en
ligne, impliquent le recours à des techniques plus complexes et à des architectures plus
sophistiquées.
La nature hétérogène des composants d’une application Web et sa complexité
entraînent l’intervention de diverses personnes pour sa construction. L’hétérogénéité
des intervenants se constate à plusieurs niveaux relatifs par exemple à leur formation, à
leurs connaissances, à leurs expériences et à leurs compétences.
Cette hétérogénéité tant matérielle que humaine a entraîné l’apparition d’une
panoplie de termes, tous liés les uns aux autres, provoquant une certaine confusion que
nous avons voulu dissiper.
Ce chapitre débute par une présentation des concepts directement liés à notre travail.
Nous avons d’abord, donné une description de l’architecture d’une application Web et
de ses différentes catégories. Ensuite, avons passé en vue les différents termes qui se
rapportant aux applications Web, en essayant d’exhiber les concepts qui s’en dégagent :
Site Web/Application Web, Page Serveur/Page Client et enfin Page Statique/Page
Interactive/Page Dynamique.
Mais au fait, …application Web ou Site Web ?
15
1.2. Application Web … ou Site Web ?
Une application Web est un programme dont les fonctionnalités sont délivrées à
travers le Web. Conallen [Con 00] explique que «les applications Web résultent de
l’utilisation de sites et de systèmes Web». Un système Web fait référence à
l’infrastructure permettant un échange d’informations entre ordinateurs. Ses éléments
essentiels1 sont donc :
-
le réseau, qui relie physiquement les ordinateurs ;
-
un poste client doté d’un navigateur. Le navigateur appelé aussi browser, est un
logiciel qui permet l’affichage, localement, de documents hébergés sur d’autres
ordinateurs du réseau. Il est l’interface utilisateur de l’application. Le HTTP
(Hyper Text Transfer Protocol) est utilisé pour communiquer entre l’interface
utilisateur et le reste de l’application ;
-
un poste hôte sur lequel un service (ou démon), appelé serveur Web, permet de
localiser et de retourner les informations demandées par le client au moyen de
requêtes.
Une application Web peut être construite à partir de composants de différentes
natures qui interagissent entre eux pour satisfaire l’utilisateur : une Base de Données,
des objets distribués ainsi que des pages Web. Les informations sont organisées dans les
pages Web. Celles-ci sont ensuite reliées par des liens, constituant ainsi un hypertexte.
Une application Web apporte une dimension supplémentaire à cette infrastructure à
travers la mise en oeuvre d’un serveur d’application. Ce dernier rend possible le
traitement des actions de l’utilisateur qui vont au-delà de simples requêtes de
navigation. Ainsi, pour Baresi [Bar 00], les sites Web présentent deux dimensions
essentielles, celle des informations et celle de la navigation, alors que les applications
Web, en revanche, en intègrent une troisième : celle des opérations. Cette position est
partagée par Conallen [Con 00], pour qui, une application Web se différencie d’un site
Web, en cela que l’application offre à l’utilisateur des mécanismes, lui permettant de
réaliser des tâches plus complexes. Par ailleurs, le résultat de ces actions se traduit par
1
Bien que non décrites ici, certaines technologies sous-jacentes aux éléments présentés sont
indispensables au fonctionnement d’une telle infrastructure. On citera par exemple les protocoles TCP/IP
(Transmission Control Protocol / Internet Protocol), HTTP (HyperText Transfert Protocol), les langages
de publication de pages Web HTML (HyperText Markup Language), XML (eXtended Markup
Language), etc.
16
une modification de l’état applicatif sur le serveur : des données sont ajoutées,
modifiées, supprimées, des actions deviennent disponibles ou ne le sont plus, etc.
Au regard de cette définition, il apparaît clairement que de nombreuses applications
peuvent être qualifiées de basées sur le Web. Ainsi, dès lors qu’une interface permet de
saisir des informations (par exemple pour s’enregistrer en tant qu’utilisateur), le serveur
d’application voit son état changer puisque les données fournies sont stockées et puis
prises en compte dans la logique applicative. Des applications Web proposent toutefois
des actions bien plus avancées : c’est notamment le cas de celles qui mettent en oeuvre
les fonctionnalités métier spécifiques d’une organisation.
Dans [Mec 99], la distinction proposée peut être rapprochée de celle de Conallen,
bien qu’elle soit subtilement différente par rapport à ce que les auteurs appellent sites
Web. Leur proposition est basée sur une analyse de la complexité des sites en regard de
deux critères : l’un est relatif aux données gérées, et l’autre relève de ce que les auteurs
nomment l’application et qui correspond aux services offerts par l’application. Le
croisement des ces deux critères – complexité des données et complexité des services –
permet à [Mec 99] de distinguer quatre catégories :
-
Les sites "de présence" sur le Web : Ils sont caractérisés par un faible degré de
complexité tant en terme de données qu’en terme de services. Leur objectif
concerne principalement la mise en ligne d'informations, à des fins publicitaires
par exemple, ou résultant d'une volonté de diffuser des informations diverses
(activités d'une association, présentations de manifestations, informations
personnelles, etc.). Généralement constitués d'un petit nombre de pages, ces sites
sont principalement construits à l'aide d'éditeurs HTML.
-
Les sites "catalogues" ou à forte intensité de données (data-intensive Web
sites) : Ils sont caractérisés par le fait qu'ils publient une masse importante de
données, selon une structure hypertexte complexe. Ils n'offrent en revanche pas
ou très peu de services. Nous assimilons ces deux catégories à la notion de sites
Web telle qu’elle est envisagée par Conallen. Les deux suivantes peuvent être
comparées à la notion d’applications Web :
17
-
Les sites orientés services : Ils ont la vocation de fournir des services spécifiques
tels que ceux offerts par les moteurs de recherche1 ou les applications de
messagerie électronique. De tels sites peuvent reposer sur des bases de données
de taille conséquente, mais la structure des données et de l'hypertexte reste
simple. La complexité est donc davantage liée aux applications sous-jacentes qui
garantissent les services, et c'est en général autour de ces aspects que s'oriente le
développement de tels sites.
-
Les Systèmes d’Information basés sur le Web (SIW) : Ils constituent la
quatrième catégorie de sites Web. Ils combinent la mise à disposition et la gestion
de données complexes avec des services interactifs sophistiqués. Les applications
de commerce électronique et les SI des organisations entrent dans cette catégorie.
La Figure 2.1 illustre le positionnement de ces catégories selon deux axes relatifs à
la complexité des données (axe vertical) et à celle des services (axe horizontal). Inspirée
de [Mec 99], cette représentation fait également apparaître la distinction établie dans
[Con 00] entre sites et applications Web, où seule la dimension applicative intervient.
Figure 1. Classification des applications Web d’après [Mec 99] et [Con 00]
La complexité des services offerts est donc un dénominateur commun aux deux
propositions.
1
Notons que, pour Conallen [Con 00], les moteurs de recherche ne sont pas considérés comme des
applications Web dans la mesure où ils ne sont généralement pas caractérisés par une modification de
l’état applicatif suite aux actions (requêtes) de l’utilisateur.
18
Dans ce qui suit, nous allons enchaîner sur la description de l’architecture des
applications Web.
1.3. L’architecture d’une applications Web
Une application Web est une application délivrée par un serveur Web sur un réseau.
Elle repose sur une architecture client/serveur à plusieurs niveaux (Tiers). L’architecture
d’une application Web reflète la répartition spatiale de ses données et la distribution
spatio-temporelle des ses composants exécutables. La configuration spatiale minimale
d’une application Web est appelée « two-tier », ou à deux niveaux. Elle ressemble au
modèle traditionnel « client-serveur », à la différence que le côté client qui représente le
navigateur, n’est qu’une partie très mince de l’application, raison pour laquelle il est
également appelé « client léger ». Il est utilisable sur de nombreux supports matériels.
Son rôle est essentiellement l’interprétation et l’affichage des pages Web à l’intension
de l’utilisateur. Les instructions exécutables qui constituent le corps de l’application
ainsi que les données qu’elle manipule résident, quant à eux, côté serveur. Le nombre de
serveurs à mettre en place peut être augmenté pour faire croître le nombre de niveaux de
l’architecture. Nous obtenons alors des configurations plus complexes, appelées « threetier » ou « multi-tier », invoquant plus d’un niveau côté serveur. Chacun des niveaux
joue un rôle bien précis dans l’application. Ainsi la dénotation des niveaux
communément admise correspond aux différents rôles qu’ils assurent dans l’application.
Pour mettre en oeuvre ces niveaux un ensemble de technologies et de modèles sousjacents sont disponibles :
-
Niveau « interface utilisateur » : il assure l’affichage de l’interface utilisateur,
sur le poste client. Les technologies invoquées à ce niveau sont celles des pages
Web : HTML, Java Script, Styles CSS. Les concepts manipulés sont alors : le
document, le style, le formulaire, le script, la balise, etc.
-
Niveau « contrôle ou logique » : il concerne le contrôle de la cohérence des
actions de l’utilisateur. Le niveau contrôle est régi par les technologies de la
génération dynamique de pages Web, souvent associées à un langage de
programmation tel que PHP, JSP (Java), ASP (C++), etc. Le modèle associé
décrit les composants d’une application client/serveur : le serveur, l’application,
la session, la requête, et le contexte (ensemble de variables) associé à chacun de
ces composants.
19
-
Niveau des «données » ou « objets » : il gère l’accès aux données de l’application
ainsi que leur mise à jour. Le niveau des données peut être objet et/ou relationnel.
Les technologies objets disponibles sont celles des langages objets utilisées pour
développer le niveau contrôle à savoir : Java et J2EE, ASP et .NET, la version
objet de PHP. Les concepts des modèles sont ceux du paradigme « objet » : la
classe, l’opération, la propriété, l’objet, etc. Lorsque les données sont persistantes
une base de donnée relationnelle est alors utilisée, soit de manière transparente
via un serveur d’application gérant la persistance des objets, soit de manière
explicite lorsque ce type de serveur n’est pas utilisé. Les SGBD relationnels du
marché constituent l’essentiel des technologies utilisées : SQL-Server, Oracle,
MySQL, Sybase. Le modèle des données est le modèle relationnel dans lequel les
notions de relation, attribut, type, clé sont utilisées
-
Niveau « inter-niveaux » ou middleware : Il assure la communication entre les
différents niveaux existants. Pour faire communiquer les différentes technologies
invoquées dans les niveaux précédents, des bibliothèques de composants (API)
existent dans le langage de développement choisi. Par exemple la bibliothèque
nécessaire à l’utilisation d’une base de données en java se nomme JDBC (Java
Data Base Connectivity). Les concepts du modèle utilisé sont : la base de
données, la connexion, la requête, le résultat, les méta-données.
Cette variété de technologies et de modèles rend l’architecture d’une application
Web dangereusement complexe. Concevoir ce type d’application nécessite en plus d’un
investissement
technologique
très
important,
un
ensemble
de
compétences
informatiques allant des réseaux aux bases de données en passant par la programmation
objet, la syntaxe HTML et plus encore.
1.4. Les Catégories d’applications basées sur le Web
Toutes les applications Web ne partagent pas forcement les mêmes caractéristiques
ni les mêmes particularités. Elles ont été conçues pour répondre à différents besoins,
impliquant ainsi différentes technologies. Nous énumérons ici sept différentes
catégories d’applications Web telles qu’elles ont été recensées par Desphande dans [Des
02]. Cette catégorisation est basée sur les fonctions remplies par l’application. Notons
que toutes les catégories sont désignées par le terme « site », même si elles reposent sur
un aspect applicatif important.
20
Cette catégorisation est présentée dans l’ordre croissant du degré de complexité des
technologies impliquées dans la construction de l’application. La catégorie la plus
simple étant les sites Web informationnels dont le but est limité à la publication de
données sur internet. La catégorie la plus complexe, du moins à ce jour, étant les sites
Web hautement dynamiques, personnalisés et adaptés à des utilisateurs individuels.
Entre les deux, il existe cinq autres catégories. Nous allons dans ce qui suit les énumérer
en donnant des exemples pour chaque catégorie.
-
Les Sites Web Informationnels, appelés également « document-centric »: Cette
catégorie de sites est un simple média de diffusion de l’information sur internet.
Ils sont souvent appelés sites Web statiques. Les catalogues, les annonces, les
bulletins d’information, les manuels techniques, les livres électroniques en sont
des exemples.
-
Les Sites Web Interactifs : Cette catégorie de sites est basée sur l’utilisation de
formulaires à renseigner par le client, ce qui donne de l’interactivité au site. Les
formulaires d’enregistrement, les jeux, les horaires de voyages, personnalisés sont
les principaux exemples de la catégorie.
La prochaine catégorie, et toutes celles qui vont la suivre, impliquent un autre acteur
dans leur architecture : le serveur d’application. Son rôle est l’exécution de la logique
applicative de l’organisation.
-
Les Sites Web supportant des Transactions : Cette catégorie de sites suppose
plus d’interactivité puisque l’utilisateur a un pouvoir de modification sur
l’application qu’il n’a pas dans la catégorie précédente. La banque en ligne ou Ebanking, le Commerce électronique, les systèmes de réservation de biens et de
services en sont des exemples.
-
Les Sites Web supportant des Workflows : Ce sont des sites Web qui supportent
les workflows au sein d’une organisation ou entre différentes organisations. Les
solutions du type B2B (Business to Business), les applications gouvernementales
administratives (E-government), les systèmes de planification et les systèmes de
gestion des inventaires sont les exemples les plus répandus de la catégorie.
-
Les Sites Web supportant un environnement de travail collaboratif : Cette
catégorie de sites supporte le « groupware », dans lequel l’aspect communication
et le partage d’information sont d’une importance capitale. Les systèmes
21
distribués d’authoring, les plateformes de E-learning, les outils de conception
collaborative en sont les exemples les plus répandus.
-
Les Sites Web supportant les communautés en ligne : Cette catégorie inclut les
groupes de chat, les systèmes de vente aux enchères, les systèmes de guidage, etc.
-
Les Portails Web: Se sont des sites Web construits à l’images des galeries
commerciales,
réunissant
des
sources
d’information
et
des
services
potentiellement hétérogènes avec un seul point d’entrée. Les portails de
commerce électronique, les portails de communautés et les moteurs de recherche
sont les exemples les plus courants.
Pour conclure, quelque soit la classification, le développement d’une application
Web peut démarrer à n’importe laquelle des catégories. Par ailleurs, une catégorie
d’applications Web est généralement plus complexe que celles qui la précèdent, mais
ceci ne signifie pas qu’elle peut entièrement les remplacer. En effet, chaque catégorie
d’application Web possède ses propres spécificités, qui la rendent plus appropriée dans
un contexte donné. Enfin, les applications Web complexes peuvent être associées à plus
d’une catégorie parmi celles citées.
Nous venons de présenter une catégorisation des applications Web. Dans ce qui suit,
nous allons enchaîner sur une catégorisation plus fine, qui concerne les différents
composants d’une application.
1.5. Les composants Web
Cette section est consacrée à la description de la structure générale d’une application
Web. Les composants qui peuvent intervenir dans une application Web étant très
nombreux et d’une grande hétérogénéité, nous allons en choisir les plus importants.
Cette figure représente une structure récapitulative des composants Web distribués
sur un réseau, elle servira de pivot pour cette section.
22
Figure 2. La structure générale d’une application Web
table 1 : Les composants Web.
Numéro Rôle
Exemple courant
1
OS Serveur
Linux, Windows
2
Serveur Web
Apach(Linux,Windoes)
IIS(NT),PWS(Win9x)
3
Scripts exécutés coté serveur
PERL(Apach,IIS,PWS)
VBSCRIPT(IIS,PWS)
JAVASCRIPT(IIS,PWS)
PHP(Apache,IIS,PWS)
JAVA(Apache,IIS,PWS)
C#,VB.NET(IIS)
4
Base de données celle-ci peut être sur la Oracle(linux,Windows)
même machine que le programme qui MySQL(Linux,Windows)
l’exploite ou sur une autre via Internet.
SQLServer(Windows)
5
OS Client
Linux,Windows
6
Navigateur Web
Netscape,Internet
Explorer
7
Scripts exécutées coté client au sein du VBscript(IE)
navigateur.
JavaScript(IE,Netscape)
Perlscript(IE)
Applets JAVA
23
Généralement, le navigateur (No 6) de la machine cliente (No 5) envoie un appel
d’une page enregistrée (sous forme de script (No 3)) sur la machine serveur (No 1), le
serveur Web (No 2) reçoit la demande de la page et la traduit en HTML si elle ne l’était
pas, durant la traduction le serveur Web (No 2) peut consulter les bases de données (No
4) pour alimenter la page HTML avec les données adéquates.
Le code HTML résultant de la traduction est envoyé vers la machine cliente (No 5),
et spécifiquement vers le navigateur (No 6) qui le traduit à son tour pour construire une
page Web complète, concernant les scripts navigateur (No 7), ce sont intégrés dans le
code HTML envoyé, et sont interprétés par le même navigateur.
A partir de l’explication précédente, on commence par détailler les pages Web qui
sont distinguées selon deux classifications1, la première distingue les pages serveur des
pages client, la deuxième qui est spécifique aux pages client donne une indication sur la
façon dont ces pages sont obtenues, Elle répertorie les pages statiques, les pages actives
et les pages dynamiques.
1.5.1. Pages Serveur / Pages Client
Les pages serveur : sont celles déployées sur le serveur. Les pages appartenant à
cette catégorie peuvent contenir des scripts serveur (par exemple PHP, ASP, etc.), et ces
scripts contiennent à leurs tour des procédures et des fonctions serveur, nécessaires pour
effectuer des opérations de control ou de calcul.
Les pages client : sont déployées aussi sur le serveur, mais les pages de cette
catégorie sont envoyées aux clients lors d’une demande. Pour étudier cette catégorie
Tilley et Huang [Til 01] proposent classifier ces pages en trois sous catégories selon
leur contenu dans le serveur : les pages statiques, les pages actives et les pages
dynamiques.
1.5.2. Pages Statiques / Pages Actives / Pages dynamiques
Tilley et Huang ont proposé une classification basée sur trois classes [Til 01] de
complexité croissante.
Les pages Web Statiques : Les pages de cette catégorie ne contiennent que du code
HTML, et Les informations qu’elles affichent sont codées par origine entre les balises
1
Il existe d’autres classifications, mais les deux citées ici sont les plus attachantes à notre sujet.
24
HTML. Ils sont construites à l’avance et stockées sur le serveur Web en attendant d’être
acheminées vers le client à sa demande. Ces pages ne présentent aucune interactivité et
ne nécessitent aucun pré-traitement (interprétation) par le serveur d’application, ce sont
donc les plus simples et les plus faciles à développer, la raison pour laquelle on peut les
trouver fréquemment, surtout dans les sites personnels.
Les pages Web Actives (Client-Side) : Appelées aussi pages Web interactives, ces
pages sont également construites à l’avance et stockées sur le serveur Web, se sont très
similaires aux pages statiques mais caractérisées par contenir un code exécutable et
d’autres composants interactifs qui leur donnent de l’interactivité. Donc ces pages sont
interactives mais elles ne sont pas dynamiques parce que leur interactivité reste locale
de fait que les scriptes dans ce cas ne peuvent être exécutés que par le navigateur chez la
machine cliente, ces scriptes sont généralement écrits en java script, et pour les
composants interactifs, ce sont soit des objets flash soit des instructions HTML
dynamiques, ou bien d’autres.
Les pages Web dynamiques (Server-Side) : Cette catégorie est la plus complexe des
trois catégories précédentes. En plus du code HTML et des composants actifs, ces pages
renferment un contenu dynamique grâce à l’interaction avec la base de données, et sont
construites à la demande (on the fly). L’interprétation du code dynamique nous donne
des pages HTML nouvelles nées, et contenant des valeurs saisis par l’utilisateur ou
consultées depuis une base de données, ce sont ces pages HTML qui sont acheminées
vers le navigateur Web du client.
1.6. HTML
l'organisme W3C (World Wide Web Consortium) chargé de la standardisation des
technologies du Web, a élaboré le langage HTML (Hyper Text Market Language)
fonctionnant sur l'ensemble des plateformes existantes : Windows, Linux, MacOS, etc.,
mais également des navigateurs (browsers) comme Netscape Communicator, Internet
Explorer, Mozilla, etc.1
En plus de son utilisation très simple et qui a contribué à sa diffusion. Ce langage est
capable de gérer la quasi-totalité des artifices du Web tels que, évidemment les liens
hypertextes, les textes formatés, les images, les vidéos ou animations, les tableaux, les
1
Voir les références [Pas].
25
formulaires, les cadres « frames », les scripts, les caractères spéciaux, les feuilles de
styles et bien d'autres choses.
Adapté à son moyen de transport (qui est généralement les lignes téléphoniques), et
à fin d’assurer une rapidité suffisante de la communication sur le Web, le langage
HTML a adopté un format de texte très compact mais aussi (par conséquence) peu
sophistiqué. C'est le bon vieux format de texte pur et dur, sans fioritures du Bloc-ntes ou
Notepad de Windows par exemple. Et de plus ce format ASCII a été amputé d'un bit (7
bits au lieu de 8)!1 Mais pourtant Html est un langage universel qui s'adapte à toutes les
plates-formes comme on a cité précédemment.2
En générale, les pages HTML comportent, en plus du texte adressé au lecteur, des
instructions pour le browser3 de celui-ci. Ces instructions seront différenciées du texte
par les signes < et > ; par exemple <html>. Ces "instructions" s'appellent des tags ou
des balises. Ces éléments jouent un rôle bien précis lors de l’affichage de la page par un
navigateur. Certains assurent la mise en page, d’autres véhiculent le contenu informatif
du site, d’autres enfin permettent la mise en place d’une structure de navigation inter et
intra pages.
Dans ce mémoire, on s’intéresse à l’aspect architectural des pages Web. Par
conséquent, certains de ces éléments sont à ignorer. En effet, les balises HTML peuvent
être divisées en deux groupes : les balises de structure et les balises de contenu. Les
balises de structure définissent la structure de la page alors que les balises de contenu
définissent le format et le style du contenu.
D’autre part, un modèle de données définit un ensemble de balises ouvrantes et
fermantes indiquant le début et la fin de chaque élément. Ces balises s’imbriquent les
unes dans les autres pour obtenir des structures de données plus complexes. En plus,
quelques balises comportent des attributs avec des valeurs correspondantes. Ce sont ces
valeurs qui donnent aux différents composants leurs caractéristiques.
1
Vous serez donc privé de certains caractères spéciaux comme le (é) pour lesquels il faudra passer par
des codes particuliers.
2
Voir les références [Luc].
3
Ce logiciel, que l'on appelle un browser, vous permet de surfer sur le Net et d'afficher sur votre écran les
"pages" qu'il a interceptées. Il y a, hélas, beaucoup de marques et de types de browsers différents. Des
simples, des archaïques ou des sophistiqués... Les plus connus sont Netscape dans sa version 2 et 3 ainsi
Internet Explorer de Microsoft mais il en existe beaucoup d'autres.
26
Chapitre 2. État de l’Art
Dans le chapitre précédent nous avons présenté des concepts du domaine de
l’ingénierie du Web, tout en détaillant les technologies associées au Web à travers la
description de l’architecture d’une application Web et de ses différentes catégories.
Comme le cas des applications traditionnelles, la modélisation des applications Web
a fait partie de plusieurs recherches et études autour du monde, surtout récemment.
Dans cette section nous allons étudier quelques modèles proposés dans la littérature
pour supporter l’architecture d’une application Web générique. Chacun d’entre eux met
l’accent sur les composants les plus intéressants de point de vu de son auteur. Ensuite
profitant de leurs expériences et de leur logique nous allons en extraire un modèle
répondant à nos besoins.
2.1. Le Modèle proposé par Ricca et Tonella : [Ric 00a ]
Commençons par le modèle proposé par Ricca et Tonella, ce modèle représente les
principaux composants d’une application Web : page HTML, code serveur (indiquant
les pages serveur), les cadres, les formulaires (avec les champs d’entrée), et les relations
les plus intéressantes reliant ces composants, comme les liens hypertextes, les flux
venants des formulaires, la création des pages à partir d’autres, et l’affichage des pages
Web dans des cadres spécifiques.
Figure 3. Le Modèle proposé par Ricca et Tonella : [Ric 00a]
27
Comme le montre la figure, ce modèle a négligé la plupart des composants affichés
dans les pages client, alors qu’il a bien décrit les aspects suivants :
-
L’interaction dynamique entre le code serveur et les pages HTML, qui est
illustrée par les relations reliant leurs entités.
-
L’interaction dynamique entre l’utilisateur et l’application, grâce aux formulaires
l’utilisateur pourrait interagir avec l’application.
-
La division des pages en des cadres « frames », et la division de ces derniers en
d’autres cadres pour afficher plus d’une page dans un seul écran, la
caractéristique qui est devenu obsolète à nos jours.
2.2. Le Modèle proposé par Conallen [Con 00]
Jim Conallen a traité cette problématique d’une manière plus globale, il croit que la
structure des applications Web est trop compliquée et distribuée, d’où apparaissent la
nécessité d’utiliser les extensions du langage UML comme les stéréotypes, les valeurs
étiquetées, et les contraints, qui sont indispensable pour modéliser les particularités des
applications Web.
Figure 4. Le Modèle proposé par Conallen [Con 00]
28
Cette partie du modèle de Conallen montre l’utilisation de ses extensions, il s’est
intéressé aux détails, au point qu’il a modélisé les deux parties : le navigateur et le
serveur. En fait, grâce aux extensions de Conallen à UML, il est devenu possible de
modéliser les applications Web de manière spécifique.
D’autre part, selon Conallen les phases globales de modélisation des applications
Web ne sont pas différentes de ceux des applications traditionnelles, en plus les mêmes
modèles peuvent être utilisés surtout dans les phases les plus génériques. Concernant la
vue statique des applications, on peut utiliser les diagrammes de classes, où les pages
serveur et client sont considérées comme des classes statiques (classes avec un seul
objet). Mais dans ce cas, ces classes sont caractérisées respectivement par les
stéréotypes << PageServeur>> et <<Page Client>> ou par des icônes adéquates. Les
variables locales utilisées dans ces pages sont considérées comme des attributs privés
caractérisant les classes associées, alors que les fonctions sont considérées comme des
méthodes privées. Les attributs et les méthodes publiques ou protégées ne sont pas
acceptées dans ces classes.
Les pages serveurs peuvent créer les pages client pour être postées aux clients, mais
ces pages ne sont pas des objets statiques parce qu’elles ne sont stockées dans aucun
lieu, elles sont symbolisées par le stéréotype <<Pages Créées>>, ces pages constituent
un cas spécifique des pages client et elles peuvent avoir des attributs et des méthodes de
la même manière de ceux statiques.
Les formulaires constituent aussi une classe de base pour Conallen, ils sont agrégés
aux pages client, et ils comportent des champs pour collecter les données.
En fait, ce ne sont pas seulement les classes qui peuvent être stéréotypées, mais les
relations peuvent l’être aussi, Conallen propose les relations stéréotypées suivantes
comme des relations génériques :
-
<<créer>> : (« builds » en anglais) une relation reliant une classe Page Serveur
avec une classe représentant la page client créée par cette dernière.
-
<<lien>> : (« links » en anglais) une relation reliant une page client avec une
autre page.
-
<<submits to>> : une relation entre une formulaire et la page serveur vers la
quelle les données sont envoyées.
29
-
<<inclut>> : (« include » en anglais) une relation entre deux pages ou bien une
page et un module bibliothèque.
Les extensions de Conallen peuvent être utilisées pour modéliser la structure
statique (en utilisant le diagramme de classe de UML), alors que le comportement
dynamique peut être représenté par les diagrammes de séquences, de collaboration,
d’activités, et d’état transition.
En plus, le modèle de Conallen peut faire l’objet de plusieurs autres extensions, par
exemple le cas du modèle proposé par Tramontana [Tra], qui permet de modéliser une
application Web à un niveau de granularité plus élevé et qui sera décrit dans le
paragraphe qui suit..
3.3. Le Modèle proposé par Tramontana : [Tra 05]
Le but de Tramontana, lorsqu’il a exhibé son propre modèle à partir de celui de
Conallen, était de trouver un modèle adéquat à son approche de rétro-conception des
applications Web. Pour lui, en utilisant le diagramme de classes de UML, les entités
principales d’une application Web peuvent être modélisées par les classes, alors que les
relations reliant ces entités sont représentées par les associations, en plus il a utilisé les
relations de composition et d’agrégation pour décrire l’imbrication des entités dans
d’autres. La figure suivante montre le modèle inventé par Tramontana.
Function
Client
Module
Client
n
n
n
faire suivre
inclut
1..n
Script Client
n
créer
Page
Statique
inclut
Classe
Serveur
Page créée
n
n
faire suivre
Classe Client
Page Web
Page Client
n
lien
n
n
n
Script
Serveur
1
1..n
Paramètre
Balise HTML
1
submit
télécharger
Formulaire
incomplet
n
1
Objet Web
Frameset
Applet Java
n
Fichier
téléchargeable
Multimedia
Objet Flash
afficher en cadre
Page Serveur
n
1
n
Objets
Interface
Fonction
Serveur
n
inclut
incomplet
Champs
1..n
Interface
courrier
Cadre
n
Interface Fichier
Serveur
Interface
BD
Figure 5. le Modèle proposé par Tramontana [Tra 05 ]
30
Selon Tramontana, les éléments de base d’une application Web sont les pages Web
qui sont : soit des pages serveur (enregistrées sur le serveur) ; soit des pages client
(crées et envoyées par le serveur vers le client qui les avait demandées). D’autre part les
pages client peuvent être classées selon leurs origines : si le contenu de ces pages était
stocké sur le serveur d’une manière permanente et fixe, ils sont appelées pages
statiques ; par contre, si ce contenu était variable et n’est généré qu’à la demande, alors
ils sont appelées pages créées.
On remarque dans ce modèle un niveau de granularité très élevé, la chose qui peut
rendre la modélisation des aspects dynamiques plus claire et plus facile. De plus les
pages statiques ont été distinguées de celle créée à la demande. Par ailleurs, les entités
de traitements dynamiques (les scripts et les modules dynamiques) ont été aussi
distinguées des classes passive (comme les images, et les séquences son et vidéo).
31
Chapitre 3. Proposition
La section suivante est le résumé d’une étude exhaustive des composants qui
interviennent dans une application Web. Pour chaque catégorie de pages Web nous
avons défini une liste de composants, et pour chaque composant nous avons défini sa
balise ainsi que la liste de ses attributs. En plus nous avons étudié les relations
susceptibles d’exister entre ces composants.
3.1. Étude des composants Web
3.1.1. Les pages Statiques :
Les pages statiques sont envoyées vers le navigateur qui les a demandées sans
aucune interprétation, parce que ces pages ne comportent que de code HTML qui est
compréhensible par ce navigateur, Le tableau suivant représente une description abrégée
d’une panoplie d’éléments HTML :
table 2: Les composants principaux du HTML
Nom
composant
Balise
Liste d’attributs
<html>
LANG="Langue"
Commentaire
DIR="Direction"
VERSION="version"
Cet élément contient
d’autres
Tête
<head>
PROFILE="Adresse
profil"
d'un
décrivant
éléments
les
caractéristiques de la
page et insérant des
scripts actifs
32
BACKGROUND="@
de
l'image"
BGCOLOR="Couleur"
TEXT="Couleur"
BGPROPERTIES="fixed"(7*)
LINK="Couleur"
ALINK="Couleur"
VLINK="Couleur"
BOTTOMMARGIN="Valeur
<body>
Corps
en
pixel"(9*)
TOPMARGIN="Valeur" en pixel
LEFTMARGIN="Valeur en pixel"
RIGHTMARGIN="Valeur"
en
pixel
MARGINWIDTH="Valeur
en
pixel"
MARGINHEIGHT="Valeur"
en
pixel
Lien
<a>
hypertext
HREF="@
cible"
TARGET="Cadre
cible"
SRC="Adresse de l'image"
NAME="Nom"
ALT="Légende"
LONGDESC="Adresse
du
document"
BORDER="Valeur"
Image
<img>
HSPACE="Valeur"
VSPACE="Valeur"
WIDTH="Valeur"
HEIGHT="Valeur"
ALIGN="top,middle,bottom,left
ou
right">
<ul>
Liste
Liste
<ol>
numérotée
Liste
des
TYPE="disc,circle,square"
OL TYPE="I,i,A,a"
START="num de depart"
<dl>
definitions
--NAME="Mail"
Formulaire
<form>
ACTION="@"
ENCTYPE="text/plain">
METHOD="Type de transmission
33
WIDTH="Valeur"
HEIGHT="Valeur"
CELLSPACING="Valeur"
<table>
Table
CELLSPADDING="Valeur"
BORDER="Valeur"
FRAME="Type de bordure"
RULES="Type de bordure"
NAME="Cadre1"
SRC="ex.htm"
SCROLLING="yes/no"
MARGINWIDTH="130"
Cadre
MARGINHEIGHT="35"
<frame>
NORESIZE
SRC="Adresse
du
document"
LONGDESC="Adresse du document"
(définissant le contenu)
Commentair
e
Définir une
feuille
de
< !--
-- >
<style>
text/css
(ou
bien)
text/javascript "
Media="Nom de médium"
style
Paragraphe
Type= "
<p>
La valeur de l’attribut
Champs
d'entrée
<input>
NAME="Nom du champ"
type
TYPE=Type de champ>
champs
détermine
d’entré
quel
on
aurai
Champs
multi lignes
<TEXTAR
NAME="Nom du champ"
EA>
COLS="Valeur"
ROWS="Valeur"
En fait, cette table ne constitue qu’un résumé des résumés effectués sur les éléments
HTML étudiés dans le cadre de ce mémoire, la plupart des autres balises sont destinées
à la mise en forme du contenu de la page, surtout les textes.
34
Il s’agit maintenant de trouver une structure selon la quelle un algorithme peut
extraire les éléments voulus et les stocker, de façon à pouvoir conserver les relations qui
existent entre eux. Nous avons opté pour l’utilisation de deux catégories de relations :
les relations d’inclusion et les relations d’utilisation.
3.1.1.1-les relations d’inclusion :
Ce sont les relations résultantes de l’inclusion d’un élément par les balises
(ouvrante et fermante) dans un autre élément. Ce phénomène est appelé
l »encapsulation ». Ainsi chaque élément peut être soit père, soit fils de l’autre.
Généralement une page HTML peut être représentée par un arbre dont la racine est
la balise <html> de laquelle partent deux branches qui correspondent respectivement
aux deux balises : <Head> et <Body>. Tous les autres composants sont imbriqués dans
l’une ou l’autre de ces deux balises. La figure suivant illustre cette description.
Figure 6. La structure d'une page HTML
Par exemple, le corps peut contenir un tableau, qui peut contenir à son tour une
image dans une cellule et un lien hypertexte dans une autre cellule, ce cas peut être
représenté par la figure suivant :
35
Figure 7. La relation d'inclusion
En fait, cette représentation peut être appliquée à tous les composants, ce qui facilite
la manipulation de la page HTML de manière récursive.
3.1.1.2-les relations d’utilisation :
Ce sont les relations représentées par le fait d’utiliser des éléments par d’autres en
indiquant les premiers comme des valeurs des attributs des derniers, en fait, ces
relations sont moins fréquentes que les relations d’inclusion, parce qu’on peut trouver
des éléments sans attributs.
L’exemple le plus simple pour illustrer ce type est d’appeler un script par un bouton
pour effectuer une fonction quelconque, l’exemple suivant illustre comment un attribut
du bouton peut lancer l’exécution du script.
36
Figure 8. La relation d'utilisation
Une relation d’utilisation peut dépasser les limites de la page pour relier l’élément
par un autre fichier, c’est le cas par exemple dans les feuilles de styles en cascade :
l’attribut (class) peut utiliser les caractéristique décrites dans une feuille de style pour
mettre en forme un élément situé dans une page différente de celle-ci.
3.1.2. Les Pages Actives (Client-Side) :
Cette catégorie de pages peut comporter en plus du code HTML, des scripts actifs
qui sont généralement écrits en java script. Dans ce tableau on a essayé de collecter
quelques composants dont le fonctionnement est actif (interprété au niveau du
navigateur ou coté client) :
37
table 3: Les composants actifs des pages Web.
Nom
composant
Balise
Liste attributs
Commentaire
CLASSEID="java:fichier
après les nouvelles
classe"
spécifications
CODETYPE="application/ja
W3C, Cette balise
va"
Objet
<object>
peut être utilisée
TYPE="Type
pour insérer soit
d'application"
multimédia
du
CODEBASE="@
de
un objet active X
chargement"
soit une séquence
DATA="Nom"
flash
soit
un
applet.
CODE="Nom de la classe"
<applet>
Applet
CODEBASE="Adresse
du
code">
C’est une classe
Java.
SRC="Adresse du média"
Vidéo
ou
<EMBED>
PLUGINSPACE="@de
l'application"
audio
TYPE="Type d'application">
Java script
<script>
Type="text/javascript"
Cette balise peut
Ou
être incluse soit
Language="JavaScript"
par
l’élément
(tête), soit par le
corps de la page
SRC="Adresse
d'un
page
contenant du code"
CHARSET="Nom
caractères">
du
jeu
Note :
on
peut
inclure
d’autre
langages
comme
de
vbscript
par
la
même balise juste
on
modifie
la
valeur de l’attribut
type
38
HTML
…
…
Ce
Dynamique
sont
des
extensions
apportées
au
HTML.
La présence des scripts interactifs, même s’ils ne concernent que la page qui les
contient et qu’ils sont de taille relativement réduite, complique l’analyse et la
compréhension de cette catégorie de pages.
3.1.3 Les pages dynamiques (Server Side) :
Les pages de cette catégorie peuvent comporter de code HTML, mais leurs
composants principaux étant les scripts dynamiques sont la source de toute interactivité
réelle dans les applications Web. Ce tableau comporte les langages Web dynamiques les
plus utilisées et connues :
table 4: Les composants Web dynamiques.
L’élément Balises
Php
Attributs
<? Php
<?
…
…
•
?>
?>
Ces trois formats
sont
Language= "php"
<script>
Commentaire
possibles
pour insérer du
code
php
dans
une page, mais le
dernier
est
rarement utilisé
Jsp,
<%
…
%>
Servlets
Asp,
Asp.net
<script>
language= "c# ou
VB.net"
runat="server"
39
Perl
# !d:\perl\bin\perl.exe
•
Perl
:
L’abréviation de
(Practical
Extracting
and
Reporting
Language)
•
ce ligne écrite en
tête de la page
indique le chemin
de l’exécutable :
perl.exe
Pour le moment, connaître les balises de début et de fin des codes dynamique est
suffisant pour nous, puisque nous ne sommes pas intéressés par la sémantique de ces
codes.
Dans la section qui suit, nous présontons le modèle que nous avons retenu pour
supporter les composants décrits dans cette section.
3.2. Le Modèle Proposé
En fait, les modèles citées précédemment (dans le chapitre : état de l’art), ont été
définis par leurs auteurs pour répondre à leurs besoins spécifiques. Conallen était
motivé par la modélisation des applications Web en phase de « conception » ; à
l’inverse, Tramontana était motivé par la rétro-conception des applications Web. Par
ailleurs, ces auteurs ont proposé des modèles qui se distinguent également par leur
niveaux de granularité : alors que le modèle de Ricca et Tonella n’a décrit que les
composants principaux, Tramontana les a tous détaillés (même les objets d’interfaces :
ceux reliant l’application Web avec un DBMS ou bien avec d’autres systèmes externes).
L’étude de ces modèles et des objectifs sous-jacents, nous a permis de mieux
appréhender notre problématique afin de définir clairement ses spécificités. Nous avons
donc défini notre propre modèle, lequel devra répondre d’un niveau de granularité
intermédiaire pour répondre de façon pertinente à nos besoins. C’est sur ce modèle que
l’outil WebAnalyser s’appuie.
40
Les paragraphes qui suivent détaillent et illustrent la construction progressive du
modèle que nous avons retenu. Nous allons argumenter de manière incrémentale chaque
bloc qui sera rajouté au modèle. Les figures intermédiaires ne seront pas référencées
dans la table des figures ; car d’une part, elles sont incomplètes et ne sont représentées
que pour faciliter la compréhension du commentaire qui la précède. D’autre part, la
construction d’un modèle se fait toujours de façon progressive, sur plusieurs itérations
et implique plusieurs « allers-retours » ; or ces figures n’englobent pas la totalité des
concepts retenus lors des itérations précédentes. Par conséquent, seule la figure
illustrant le modèle final sera référencée.
Ces paragraphes présentent le cœur même de notre contribution théorique à cette
problématique.
En premier lieu, les pages sont l’unité de base dans une application Web et elles
peuvent être de deux catégories : les pages coté client et celles coté serveur. La page
coté client n’est pas nécessairement écrite en html puisqu’à l’origine elle peut être écrite
en un langage de programmation (Web dynamique) ; elle peut aussi être hybride
(contenir un mélange des deux langages).
Dans notre modèle, cette différenciation sera prise en compte en distinguant les
pages serveur des pages clients. De ce fait la, les pages statiques décrites par
Tramontana comme des pages clients sont considérées maintenant des pages serveur
puisque la seule différence entre eux c’est l’interprétation effectuée au niveau du
serveur avant d’être acheminées vers le poste client.
La figure suivante montre la relation (créer) entre deux pages : serveur et client,
toute en généralisant ces deux dernières par une entité (page Web).
PageClient
Page Client : la page telle
qu’elle est affichée chez le
create
PageWeb
client.
Page Serveur : la page telle
PageSrveur
qu’elle est enregistrée sur le
serveur
41
Une page cotée serveur peut inclure un script dynamique, comme elle peut être
écrite totalement en HTML. Le script dynamique est constitué de classes et de fonctions
dont l’objectif est de créer (ou bien de contribuer à la création) des éléments affichés sur
la page Client. Nous pouvons donc énoncer qu’un élément appartient toujours à une
page Web. La figure suivante montre ces relations :
PageClient
_
PageWeb
_
Element
_
create
_
PageServeur
_
ScriptDynamique
_
Classe
_
createElement
_
Function
_
On remarque que (ScriptDynamique) est reliée grâce à la relation (createElement)
avec (Element), cette association est utile parce que le fait de déterminer le script
responsable de créer un élément quelconque peut rendre la modification de cet élément
une opération plus facile et plus rapide.
D’autre part une page Web peut être composée de « framesets » qui peuvent être
divisées à leur tour soit en d’autre « farmesets » soit en des cadres à fin d’afficher
d’autres pages.
42
Frame
divisé en
divisé en FrameSet
afficher
PageWeb
PageClient
create
Element
PageServeur
Commençons à spécialiser les éléments affichés dans une page Web. En premier
lieu, chaque élément inclue d’autres éléments d’une manière imbriquée, à l’exception de
quelques éléments simples comme les commentaires et les images, la figure suivante
montre les éléments les plus importants qui sont : les liens hypertextes, les tables, les
objets multimédia, les formulaires, les extraits texte, les commentaires, et les scripts
actifs.
LienHypertexte
_
_
Table
ScriptActif
_
Commentaire
_
Element
_
Texte
_
ObjetMultimedia
_
Formulaire.
_
43
Comme le cas des scripts dynamiques, les scripts actifs peuvent être divisées en des
modules, qui sont soit des fonctions soit des classes, et ces modules peuvent à leur tour
être composés d’autres modules comme illustré par cette figure :
ClasseClient
Element.
ScriptActif
Module
FonctionClient
Les liens hypertextes acheminent le navigateur vers une autre page Web en affichant
cette dernière dans un cadre bien déterminé
Frame
LienHypertexte
divisé en
divisé en FrameSet
vers
PageWeb
Element.
Concernant les formulaires, ces composants sont attachés sur une page coté serveur
à travers une relation « submit », dans ce cas la page cible ne doit pas être une page coté
client vu la nécessité de traiter les valeurs envoyées par le formulaire.
44
PageClient
PageWeb
Element.
create
submit
PageServeur
Formulaire
La figure 9 illustre le modèle global retenu dans notre approche. Il regroupe tous
les aspects énumérés précédemment. Ce modèle décrit une application Web générique.
Par conséquent, n’importe quelle application réelle à traiter sera une instance de ce
modèle.
LienHypertexte
Frame
Table
Commentaire
divisé en
divisé en FrameSet
PageClient
ClasseClient
achemine vers
PageWeb
Element
ScriptActif
Module
create
PageServeur
FonctionClient
submit
include
Formulaire.
ScriptDynamique
ObjetMultimedia
Texte
createElement
Fonction
Classe
Figure 9. Le Modele Global Retenu
45
Au besoin, ce modèle peut faire l’objet d’extensions afin de supporter d’autres
catégories de composants Web.
3.3. Le logiciel
« La différence entre la théorie et la pratique, c’est qu’en
théorie, il n’y a pas de différence entre la théorie et la pratique mais qu’en pratique,
il y en a une. »
Jan van de Sneptscheut
Notre contribution théorique est certes intéressante … mais pour prouver qu’elle est
pertinente sa validation est indispensable. Nous avons donc implémenté notre outil
WebAnalyser en se basant sur le modèle retenu pour pouvoir le valider.
3.3.1. Description générale
L’architecture interne de notre outil est illustrée par la figure suivante :
Figure 10. L'architecture du logiciel "Web Analyser"
46
WebAnalyser est basé sur quatre composants : l’aspirateur, le nettoyeur, le parseur et
l’éditeur ou « visualiseur ».
-
l’aspirateur 1: c’est un Logiciel destiné a copier l'intégralité d'un site Web sur le
disque dur d'un ordinateur. Il se connecte à une page, désignée par son utilisateur,
et traque sur celle-ci tous les liens et appels à des fichiers extérieurs (images,
vidéos, animations flashs ou autres). Chaque fichier ainsi localisé est copié sur le
disque dur de l'ordinateur effectuant ainsi l'aspiration. Le site est alors consultable
en local, sans être connecté à Internet. L’aspirateur n’intervient que dans le cas où
le site n’est disponible que sur le Web.
-
Le Nettoyeur : le code HTML contient très souvent des erreurs. Même si elles ne
sont pas problématiques pour un navigateur, ces erreurs le sont pour tout autre
traitement automatique. D’où la nécessité d’un nettoyeur pour corriger les
éventuelles erreurs syntaxiques qui peuvent apparaître dans le code HTML. Nous
avons retenu Tidy [Rag], un outil en ligne qui retourne des pages HTML
syntaxiquement bien formées.
-
Le parseur : c’est le cœur même de notre outil. Il traite (« parse ») les fichiers
d’un site (enregistrés sur le disque dur) et utilise un « mapper »2 pour enregistrer
les extraits dans la base de données.
-
Le visualiseur : c’est un éditeur graphique. Il affiche les composants de
l’application sous une forme arborescente ; ainsi l’utilisateur peut naviguer entre
les différents composants. Il s’agit d’une interface graphique conviviale.
-
Les sections suivantes présentent les étapes suivies lors du développement de
l’outil WebAnalyser.
3.3.2. Les alternatives … et choix
Nous étions confrontés à plusieurs alternatives quant au choix des composantes
techniques nécessaires au développement de cet outil. Les paragraphes qui suivent
présentent et justifient les choix retenus.
1
Selon l’url :http://www.dicodunet.com/annuaire/def-26-aspirateur-de-site.htm
2
Un “Mapper” est une classe java qui se charge d’extraire les valeurs des attributs d’un objet et les
enregistrer sous la forme d’un enregistrement dans une base de données relationnelle.
47
3.3.2.1. Le langage de programmation utilisé
Choisir java comme langage de développement ne nécessitait pas des études
comparatives, parce que ce langage représente un résultat de toutes les modifications
apportées aux langages précédents, en plus, la richesse des libraires du Java et sa
portabilité sont des avantages convaincants pour le choisir. Les points suivants
expliquent en résumé les avantages de l’utilisation de ce langage, au moins dans le
développement de cet outil :
-
Le parseur : dans la section (3.3.2.2) on va aborder l’utilisation du parseur
HTML qui est disponible en toute API de java. Des classes sont prêtes à l’usage
avec des fonctions couvrantes la plupart des besoins des développeurs.
-
La connexion à la base de données : en utilisant un pilote adéquat la connexion à
une base de données devient une tache facile. D’autre part, java supporte un
ensemble de classes permettant de gérer cette connexion, et beaucoup de
technologies de « mapping » ont été créées spécifiquement.
-
L’interface graphique : java supporte plusieurs moyens pour créer des interfaces
graphiques répondant à tous les besoins et facilitant considérablement le travail.
-
La portabilité : un logiciel écrit en java est généralement indépendant de la
plateforme et du système d’exploitation. Les utilisateurs du system Unix peuvent
donc profiter de notre outil exactement comme les utilisateurs de windows.
-
La facilité de codage : java élimine toutes les difficultés qu’on éprouvait en
écrivant des codes avec le pointeur puisqu’on est devenu capables de gérer
automatiquement l’allocation de mémoire qui minimise son encombrement.
Tous ces avantages nous ont confortés dans le choix de java comme langage de
programmation pour développer notre outil.
3.3.2.2. Le parseur
En fait, le cœur de ce logiciel est un parseur, spécialisé au langage HTML. Mais
avant, que signifie parseur ?
La définition citée dans l’encyclopédie « Wikipedia » :
“In computer science and linguistics, parsing (more formally syntax analysis) is the
process of analyzing a sequence of tokens to determine its grammatical structure with
respect to a given formal grammar, A parser is a computer program that carries out this
48
task, it is a component of a compiler. Parsing transforms input text into a data structure,
usually a tree which is suitable for later processing and which captures the implied
hierarchy of the input. Lexical analysis creates tokens from a sequence of input
characters and it is these tokens that are processed by a parser to build a data structure
such parse tree or abstract syntax tree”.
D’après cette définition générique, un parseur est un programme qui analyse une
chaîne de caractères pour déterminer sa structure grammaticale en respectant une
grammaire donnée. Dans notre cas, un parseur doit pouvoir extraire des blocs de code à
partir d’un document HTML. Cette extraction peut être supportée par une DTD
décrivant la structure d’une page HTML.
Donc l’input de notre parseur sera des pages HTML, et l’output sera des blocs de
code HTML accompagnés de quelques informations pertinentes.
Nous avions le choix entre développer notre propre parseur ou utiliser un parseur
disponible. La flexibilité des parseurs existants était un argument convainquant. Nous
avons donc opté pour cette seconde alternative. En java, on a trouvé deux types de
parseurs disponibles comme des API (parmi d’autres) : le « HTML parser », et la classe
« Lexer » :
1) la classe Lexer :
Figure 11. La classe Lexer
49
Cette classe « parse » le flôt HTML en des noeuds, chaque un de ces noeuds
représente un élément HTML avec soit deux balises (ouvrante et fermante), soit une
seule balise dans le cas des éléments simples comme les images.
Les noeuds résultants de ce parseur sont de trois types : commentaire, texte ou
balise.
Les nœuds de type « commentaire » et « texte » représentent respectivement les
commentaires et les textes intégrés dans une page HTML, alors que ceux de type
« balise » représentent les autres éléments.
2) le parseur « HTML parser »:
Ce parseur utilise deux classes Java prédéfinies, la classe (ParserDeligator), et la
classe (ParserCallback), à partir de la documentation java on a extrait leurs définitions
comme suit :
Figure 12. La classe Parser
Figure 13. La classe HTMLEditorKit
50
Le point de départ, c’est La classe ParserDelegator qui « parse » un flux HTML et
avertit un objet ParserCallback passé en paramétre de l’état du « parsing ».
La classe ParserCallback implémente les opérations suivantes :
public void flush() throws BadLocationException
public void handleText(char[] data, int pos)
public void handleComment(char[] data, int pos)
public void handleStartTag(HTML.Tag t,MutableAttributeSet a, int pos)
public void handleEndTag(HTML.Tag t, int pos)
public void handleSimpleTag(HTML.Tag t,MutableAttributeSet a, int pos)
public void handleError(String errorMsg, int pos)
public void handleEndOfLineString(String eol)
Pas de besoin pour le moment d’expliquer les rôles de ces opérations mais un
exemple simple qui fait extraire tous les textes d’un document HTML n’est pas mal :
HTMLEditorKit.ParserCallback callback = new HTMLEditorKit.ParserCallback ()
{
public void handleText(char[] data, int pos) {
System.out.println(data);
}
};
Reader reader = new FileReader("myFile.html");
new ParserDelegator().parse(reader, callback, false);
Ce parseur est « DTD driven », c'est-à-dire qu’il travaille selon un DTD données,
pour le moment ce n’a pas de sens, mais c’est un avantage grâce au quel on peut utiliser
ce parseur pour extraire des données à partir des documents des types différents.
Notre choix s’est fixé sur ce dernier.
51
3.3.2.3. Stockage et sauvegarde de la base de données
Notre application doit être capable de stocker des données extraites à partir des
pages Web, donc il est nécessaire qu’elle implémente une base de données, les données
à stocker seront des différents types, mais généralement, de type texte pour les
appellations des balises, de type entier pour leurs positions, et de type (blob) pour les
extraits de texte.
L’outil le plus efficace pour stocker des données de manière structurée et centralisée
reste une base de données, d’où c’est très intéressant de choisir le système de gestion de
base de données (SGBD) le plus adapté à nos besoins spécifiques.
Une base de données possède des tables contenant les données que l’on souhaite
stocker, sur celles-ci on peut effectuer des requêtes, en utilisant un langage spécifique
(SQL Standard Query Language) à fin de gérer l’ensemble des données, c'est-à-dire : les
opérations de lecture, de suppression et de modification.
Notre parseur aura besoin d’insérer et de consulter des enregistrements d’une
manière un peu stable, c'est-à-dire les requêtes dont on aura besoin seraient fixées dés le
début. Nous présentons ici une petite étude comparatif entre deux solutions gratuites :
PostgreSQL et MySql.
table 5 : Comparaison MySq l 5.0 X Postgre 8.1
Fonctionnalités
MySQL 5.0
Postgre 8.1
Support de clés étrangères
Oui
Oui
Vues
Oui
Oui
Procédures stockées
Oui
Oui
Triggers
Oui
Oui
Unions
Oui
Oui
Jointures complètes
Non
Oui
Contraintes
Non
Oui
Héritage de table
Non
Oui
Curseurs
Partiellement (seulement en Oui
lecture)
Supporte IPV6
Non
Oui
Driver JDBC
Oui
Oui
52
a)MySQL
MySQL fonctionne sur beaucoup de plateformes, de plus la plupart des langages
utilisés aujourd’hui sont capable d’interagir avec lui.
Depuis la version 4.1 le MySQL intègre les requêtes imbriquées et les tables
InnoDB permettant de gérer les transactions et les verrous au niveau des lignes, à
propos du codage des caractères c’est maintenant disponible sur plusieurs octets.
D’autre part MySQL offre de très bon résultat en terme de performances et rapidité
d’accès, il est très rapide, multithread, robuste et multi-utilisateur. Les raisons pour les
quelles il est très utilisé avec beaucoup de technologies.
b) PostgreSQL
PostgerSQL est un système de gestion de base de données développé par
(PostgreSQL Global developpement group). Ce system est très utilisé aujourd’hui grâce
aux nombreux avantages techniques qu’il possède : comme les requêtes imbriquées, les
transactions, les vues, les triggers et l’héritage des tables. PostgreSQL propose donc de
nombreuses fonctionnalités, mais dont on n’a pas besoin. Notre choix s’est donc porté
sur MySQL en considérant le facteur rapidité.
3.3.2.4. Persistance des données
Les données extraites par l’outil proposé sont stockées dans une base de données
relationnelle, par exemple, au biais de l’API JDBC on peut connecter une application
java avec une base de données relationnelle, mais comment stocker des objets Java dans
une base de données relationnelle ?
Cette question demeure jusqu'à nos jours
problématique !
Pour palier à ce problème beaucoup des technologies manipulant des bases de
données objets sont proposées, mais pratiquement, la plupart des développeurs préfèrent
faire ce qu’on appelle « mapping ». Etant une solution intermédiaire le « Mapping »
correspond à des technologies permettant de faire le passage entre les objets traités par
les langages orientés objets et des enregistrements stockables dans des bases de données
relationnelles.
Les solutions les plus abordables pour faire du « mapping » sont : Hibernate et
EJBs, qui font l’objet de cette étude comparative en ajoutant le JDBC.
53
table 6 :Comparaison JDBC X Hibernate X EJBs.
Fonctionnalités
JDBC
Hibernate
EJBs
Mise en place
Très simple
Apprentissage
Apprentissage
nécessaire
nécessaire
du Oui
Oui
Oui
Persistance d’objet Non
Oui
Oui
Oui
Oui
Indépendance
SGBD
Java
Mapping des Objets Non
Java
Création de la base Lui fournir le script Génération du code de données
SQL
SQL
automatiquement
Bufferisation
des Non
données
fin
a
d’éviter
connexions
Oui
Oui
les
a
la
base.
Déploiement
Intégration du pilot Intégration
JDBC dans le JDK
librairies
des Nécessite
dans
un
le conteneur d’EJBs
projet
Configuration
-
Fichier
XML
annotations Java
ou Fichier
XML
ou
annotations Java
a)JDBC :
JDBC est l’acronyme de « Java DataBase Connectivity » et désigne une API définie
par SUN pour permettre un accès aux bases de données relationnelles (SGBD) avec
Java.
b) Hibernate :
Hibernate est une surcouche à la base de données. Elle fournit un ensemble de
méthodes et fonctions permettant de rendre persistants les objets Java d’une application.
Il faut donc dans un premier temps permettre à Hibernate d’accéder au système de
54
gestion de base de données utilisé en lui fournissant les paramètres adéquats. On peut
ensuite définir les règles qui permettront à nos objets Java de devenir persistants. Cette
étape se nomme le « Mapping » de données. En effet les classes Java de notre
application seront par ce processus représentées par des tables dans notre base de
données. Le « mapping » permet de définir les différentes propriétés des tables dans
notre base mais aussi les relations qu’il peut exister entre celles-ci.
Il n’y a pas besoin d’expliquer ici les configurations de Hybernate mais cette figure
représente une vue globale de Hibernate dans une application gérant une base de
données.
Figure 14. L'architecture de Hibernate
Cette figure montre la séparation entre l’application et la base de données réalisée
grâce à la couche Hibernate qui est chargée de faire l’interaction entre les deux autres
couches.
c) EJBs
Les EJB sont des composants qui possèdent alors certaines caractéristiques comme
la réutilisabilité, la possibilité de s’assembler pour construire une application, etc. Les
EJB et les beans n’ont en commun que d’être des composants. Les javas beans sont des
composants qui peuvent être utilisés dans toutes les circonstances. Les EJB doivent
obligatoirement s’exécuter dans un environnement serveur dédié. Les EJB sont
parfaitement adaptes pour être intégrés dans une architecture trois tiers ou plus. Dans
une telle architecture, chaque tiers assure une fonction particulière :
55
-
le client (léger) assure la saisie et l’affichage des données ;
-
Sur le serveur les objets métiers contiennent les traitements. Les EJB sont
spécialement conçus pour constituer de telles entités ;
-
Une base de données assure la persistance des informations.
Les EJB s’exécutent dans un environnement particulier : le serveur d’EJB. Celui ci
fournit un ensemble de fonctionnalités utilisées par un ou plusieurs conteneurs d’EJB
qui constituent le serveur d’EJB. En réalité, c’est dans un conteneur que s’exécute un
EJB et il lui est impossible de s’exécuter en dehors.
Figure 15. L'architecture interne de l’EJBs
Il existe de nombreux serveurs d’EJB commerciaux : BEA Weblogic, IBM
Webshere, Sun IPlanet, Macromedia JRun, Borland AppServer, etc. Il existe aussi des
serveurs d’EJB open source dont les plus avancés sont JBoss et Jonas.
Selon la table de comparaison au dessus, le JDBC ne fais du « mapping » comme les
deux autre solutions, mais pourtant on ne va pas utiliser ces deux bonnes solutions à
cause des contraintes de temps, on est d’accord que leur utilisation minimise bien le
temps de développement mais c’est le contraire pour leur apprentissage !
On a décidé de n’employer que JDBC de manière simple en créant une « mapper »
spécial, il s’agit d’une classe java dont le rôle est de faire un « mapping » pour des objet
bien déterminés, ce n’aura pas les avantages des autres solutions mais c’est suffisant
pour notre logiciel à cette étape.
56
3.3.2.5. Cycle de vie
Les spécificités des applications Web (changement rapide, apparition de nouvelles
technilogies, etc.) nous imposent d’adopter pour le développement de notre outil un
cycle de vie itératif et incrémental.
Mais pour définir une séquence d’étapes, partiellement ordonnées, on a besoin d’une
méthode reposant sur UML1, comme le processus unifié2, qui est très utile dans le cas
des grands projets. Dans notre cas, et pour simplifier les choses, on va suivre une
méthode issue de celle présentée par Roques [Roq 02] dans son livre « UML- Modéliser
un site e-commerce». La méthode présentée par Roques est simple et générique et se
situe à mi-chemin entre le processus unifié, qui constitue un cadre général très complet
de processus de développement, et XP3 (eXtreme Programming) qui est une approche
minimaliste à la mode centrée sur le code. Cette méthode résulte de plusieurs années
d’expérience sur de nombreux projets dans des domaines variés. Elle a donc montré son
efficacité dans la pratique. En plus, cette méthode est caractérisée par les avantages
suivants :
conduite par les cas d’utilisation, comme le processus Unifié mais bien plus simple ;
relativement légère et restreinte, comme XP, mais sans négliger les activités de
modélisation en analyse et conception ;
Fondée sur l’utilisation d’un sous-ensemble nécessaire et suffisant du langage UML
(modéliser 80% des problèmes en utilisant 20% d’UML).
Cette méthode divise le processus du développement d’un logiciel en quatre phases,
comme suit :
- Phase d’identification des besoins et spécification des fonctionnalités.
- Phase d’analyse.
- Phase de conception.
1
UML (« Unified Modeling Language » soit langage de modélisation objet unifié) est né de la fusion des
trois méthodes qui se sont imposées dans le domaine de la modélisation objet au milieu des années1990:
OMT, Booch et OOSE. D’important acteurs industriels (IBM, Microsoft, Oracle, DEC, HP, Rational,
Unisysetc.) s’associent alors à l’effort et proposent UML 1.0 à l’OMG (Object Management Group) qu’il
accepte en novembre 1997 dans sa version 1.1. La version d’UML en cours est UML 2.0 qui s’impose
plus que jamais en tant que langage de modélisation standardisé pour la modélisation des logiciels.
2
Le processus unifié est un processus de développement logiciel, itératif, centré sur l’architecture, piloté
par des cas d’utilisation et orienté vers la diminution des risques.
3
L'Extreme Programming (XP) est une méthode agile de gestion de projet informatique adaptée aux
équipes réduites avec des besoins changeants. Elle pousse à l'extrême des principes simples, cette
définition a été prise de l’url : http://www.techno-science.net/?onglet=glossaire&definition=723.
57
- Phase d’implémentation.
La première phase utilise un diagramme de cas d’utilisation, puis un diagramme de
séquence système, et en fin une maquette d’interface d’IHM 1(non couvert par UML).
Évidemment, ces diagrammes doivent être génériques à cette étape là, il s’agit d’une
étape préparatoire qui décrit bien les grandes lignes de l’application.
La transition vers la modélisation objet est le premier apport de la phase d’analyse,
qui décrit, pour se faire, un modèle du domaine2, en fait, ce modèle constitue une
version primitive du diagramme de classe. Une fois le modèle du domaine est élaboré,
on utilise un diagramme de classes participantes qui effectue la jonction entre tous les
artefacts, puisque ce diagramme modélise trois types de classes d’analyse : les
dialogues, les contrôles et les entités, ainsi que leurs relations. Le troisième diagramme
utilisé dans la phase de l’analyse est appelé Diagramme d’activités de navigation, qui
offre la possibilité de représenter graphiquement l’activité de navigation dans l’interface
en produisant des diagrammes de navigation.
Passons maintenant à la troisième phase, on s’y sert de deux types de diagrammes,
les diagrammes d’interaction qui ont pour but d’attribuer précisément les responsabilités
de comportement, et ceux de classes de conception qui serviront pour l’implémentation.
Le diagramme de classes de conception final doit être complet et compatible avec le
langage de programmation utilisé dans la phase suivante.
Selon cette méthode la dernière phase décrite est l’implémentation, dans cette phase
on écrit le code et on crée la base de données, toute en utilisant les diagrammes élaborés
précédemment.
3.3.3. Le Dossier de Conception de WebAnalyser
Comme nous avons décidé précédemment, la méthode présentée par Roques serait
notre cycle de vie de développement utilisant le langage de modélisation UML (Unified
Modeling Language), dans le cadre de cette partie on explique bien les différentes
étapes constituant ce cycle de vie, toute en ajoutant quelques étapes nécessaires comme
l’étude de faisabilité.
1
Une maquette d’IHM (Interface Homme-Machine) est un produit jetable permettant aux utilisateurs
D’avoir une vue concrète mais non définitive de la future interface de l’application .La maquette peut très
bien consister en un ensemble de dessins produits par un logiciel de présentation ou de dessin.
2
En fait, L’analyse du domaine est une étape totalement dissociée de l’analyse des besoins, Elle peut
donc être menée avant, en parallèle ou après cette dernière.
58
3.3.3.1 Etude de faisabilité
Un des apports intéressants de suivre un cycle de vie en créant une application c’est
posséder des documentations dédiées, au biais de laquelle on peut comprendre la
structure de cette application.
Voici un petit exemple pour montrer l’utilité de notre outil :
Voici une page HTML :
Figure 16.Le code d'une page HTML
Ce n’est qu’une page HTML (simple !) mais ouverte avec un Bloc-notes et pas
un navigateur Web, imaginons que l’on ait besoin de modifier un élément quelconque
(une image par exemple), en chercher la balises <img>, puis en modifier les attributs <
src=XXX >, ensuite, rapidement l’enregistrer et l’ouvrir par le navigateur …Trois
situations peuvent se présenter :
notre modification était la bonne … quel bonheur !
nous avons modifié une autre image … on doit refaire une double manipulation :
rectifier l’erreur et refaire le changement en espérant de tomber cette fois sur la bonne
image.
Enfin, une troisième possibilité dramatique : le navigateur n’affiche rien car on a
commit une erreur lexicale !
Face à ce scénario, notre outil WebAnalyser est la planche de salut ! Il nous fournit
la position de chaque composant de la page avec sa liste d’attributs et nous donne la
59
possibilité de le modifier avec en prime un nettoyeur qui veille sur la qualité du code
HTML.
Question : Ce scénario est-il suffisamment fréquent pour nous pousser à développer
un outil dédié ?
Réponse : A notre ère tout change rapidement surtout les applications Web dont la
moyenne de vie (selon des études) ne dépasse pas les quatre ans. Un outil facilitant
cette tache est indispensable !
3.3.3.2. Identification des besoins et spécification des fonctionnalités :
A -Identification et représentation des besoins : diagramme de cas
d’utilisation.
Extraire les coordonnées et les caractéristiques de chaque élément dans la page
HTML est le rôle de notre outil. Ceci nous permettra de modifier un élément spécifique
en toute sécurité.
L’input de l’outil sera un site Web indiqué soit par son chemin s’il était enregistré
sur un ordinateur client, soit par son URL s’il était hébergé sur le Web. En plus, vu la
multiplicité et la diversité de composants Web, le logiciel doit donner à l’utilisateur la
possibilité de choisir les éléments qui l’intéressent, pour ne pas le surcharger d’éléments
inutiles.
Pour l’output : une représentation de l’application Web montrant ces différents
éléments a différents degrés de granularité. Les liens reliant ces éléments doivent
également être gérés afin de suivre les répercutions de chaque changement.
Cette figure représente une description superficielle (boite noir) de l’outil :
Granularité
L’outil doit permettre à l’utilisateur de gérer plusieurs applications Web
simultanément.
60
Modèle de métier
Le modèle du métier suivant montre généralement les fonctionnalités de base de ce
logiciel avec l’acteur unique qui les utilise.
Créer un nouveau projet ou ouvrir un
projet établit précédemment
Spécifier un site
l'utilisateur
Naviguer sur les composants du
site
modèle du mètier
Modèle des cas d’utilisation
Pour plus de détaille le modèle du cas d’utilisation suivant décrit toutes les
fonctionnalités dont ce logiciel se chargerait.
61
une fois le
(parsing) est
terminé
avoir de l'aide
Naviguer sur les composants
dans le cas où le
site est sur le web
choisir entre les projets créés
precedamment
<<extend>>
spécifier le site
aspirer le site désiré
utilisateur
e.x.:les composants
qui pourraient etre
extraites
fixer les options specifiques a
chaque projet
ajouter des mises a jour
personaliser le logiciel
au moment de l'installation
ou à tous moment
modèle du C.U. detaillé
Figure 17. Le Modèle des cas d'utilisation
Ne décrivant pas des fonctionnalités futures, (comme la possibilité de modifier les
composants), ce modèle indique une possibilité d’aspirer le site s’il n’était pas
enregistré sur le disque dur, en suite, le logiciel fonctionne selon deux types d’options :
les options personnelles qui sont configurées pour la première fois au moment de
l’installation du logiciel et qui concernent l’ergonomie générale, ces configurations
peuvent être modifiées à tous moment après l’installation.
les options spécifiques à chaque site (projet), et qui sont définis au démarrage de ce
projet (pour les modifier, l’utilisateur doit créer un nouveau projet pour le même site).
Une fois l’outil exécuté sur une application Web, l’utilisateur aura les différents
accès à une arborescence de ses différentes composantes (extraites selon les options
spécifiées), et stockés dans la base de données.
B -Spécification détaillée des besoins : diagrammes de séquence système.
Le diagramme de cas d’utilisation ci-dessus montre les besoins fonctionnels que doit
satisfaire le logiciel :
•
Spécifier le site ;
•
Choisir entre les projets créés précédemment ;
62
•
Naviguer sur les composants.
Les besoins non fonctionnels :
•
Personnaliser le logiciel ;
•
Fixer les options spécifiques à chaque projet ;
•
Ajouter des mises à jour ;
•
Avoir de l’aide.
Selon la méthode qu’on suit on doit détailler chaque cas d’utilisation à travers un
scénario générique, mais puisque nos cas d’utilisation sont simples et unitaires, on ne
voit aucune nécessité de les spécifier chacun à part. Nous proposons donc un seul
diagramme de séquence en considérant le logiciel comme une boite noire :
63
Modèle de séquence simple (boite noire), représentant tout le système comme une
seule unité :
:logiciel
: utilisateur
installer
definir des configurations personnelles
demarrer logiciel
specifier chemin site
si nouveau projet
si le chemin est un URL
alors aspirer le site
definir options de ce projet
demarrer (parsing)
parser(site)
si ouvrir
choisir projet
afficher (resultat,con.per.)
naviguer
quitter()
enregistrer?(oui/non)
repondre
si (non) supprimer le projet
X
Figure 18. Un Modèle Générique de Séquences
64
C -Maquette de l’IHM de l’application (non couvert par UML).
Selon notre méthode, cette phase consiste à suggérer des maquettes non définitives
de l’interface graphique, pour en avoir une vue concrète, nous avons élaboré ces
exemples :
Pour la fenêtre d’accueil cette maquette pourrait donner à l’utilisateur une idée sur le
logiciel et lui offrir la possibilité, soit de créer un nouveau projet, soit de choisir un
projet préétablit, en plus l’utilisateur peut demander de l’aide s’il en a besoin.
Figure 19. La fenêtre principale du WebAnalyser
Dans le cas ou l’utilisateur choisit l’option « créer un nouveau projet » le bouton
(personnaliser) va conduire l’utilisateur vers cette maquette (en dessous) qui lui permet
de spécifier les éléments à extraire :
65
Figure 20. La fenêtre de personnalisation des balises à extraire par WebAnalyser
Généralement il ne reste que deux fenêtres principales, la première a pour but
d’afficher à l’utilisateur une barre d’avancement pour lui décrire l’état du parseur, et la
dernière, qui est la plus importante, se chargera de présenter le contenu de la base de
données à l’utilisateur sous la forme d’une arborescence.
66
3.3.3.3. Phases d’analyse
Les phases précédentes s’apparentent à une analyse fonctionnelle classique. Celle-ci
demeure limitée lorsque nous visons une modélisation objet. Les phases suivantes vont
nous aider à opérer une transition véritable vers cette modélisation objet.
A- Analyse du domaine : modèle du domaine.
Les entités suivantes représentent les trois classes de base constituant notre logiciel,
c’est un modèle de domaine ou la modélisation est générale et les classes sont décrites
seulement par leurs attributs :
Projet
(from NewClass)
nomProjet
chemin
listeBalises
compose
Page
(from databaseComponent)
chemin : String
nompage : String
0..n
/ type
contient
Element
(from databaseComponent)
position : Integer
balise : String
listeAttributs
1
elementPere : Element
longueur : Integer
Figure 21. Le Modèle du Domaine
On remarque que ce diagramme ne comporte ni des classes d’interface graphique ni
des classe de contrôle (comportant des méthodes). On ne modélise ici que les classes
métier, dont le rôle est de permettre à des données et à des relations d’être stockées dans
une base des données.
67
Le diagramme précédent peut être détaillé comme suit :
LienHypertexte
listeElementsInclus
pourvoir
0..1
1..n
Table
caption : String
listeElementsInclus : Element
0..n
includeLien
includeTable
0..n
0..n
Frame
IdFrame : String
1
0..n
0..n
0..1
0..1
Page
contient
chemin : String
nompage : String
0..n
1
/ type
Element
position : Integer
0..1
balise : String
listeAttributs
elementPere : Element
longueur : Integer
Texte
extraitTexte : String
0..n
Multimedia
/ src : String
/ typeMultimedia : String
/ typeImage : String
0..n
0..1
afficher
includeForm
submitVers
Formulaire
0..n
listeElementsInclus
0..1
ScriptDynamique
/ langue : String
code : String
commentaire
extraitCommentaire : String
Figure 22. Diagramme de Classes Entités
B- Diagramme de classes participantes.
A partir des phases précédentes on a obtenu des artefacts des types divers, mais
comment interagissent ces artefacts entre eux ? En fait, modéliser les relations
rattachant chaque artefacts aux autre est une procédure nécessaire, et pour ce faire on va
utiliser ce qu’on appelle (Diagramme de classes participantes). Un diagramme de
classes participantes est constitué de trois types des classes comme suite :
Les classes de dialogues : Les classes qui permettent les interactions entre l’IHM et
les utilisateurs sont qualifiées de dialogues. Ces classes sont directement issues de
l’analyse de la maquette.
68
Les classes de contrôles : Les classes qui modélisent la cinématique de l’application
sont appelées : Contrôles. Elles font la jonction entre les dialogues et les classes métier
en permettant aux différentes vues de l’application de manipuler des informations
détenues par un ou plusieurs objets métier.
Les classes entités : Les classes entités, qui proviennent directement du modèle du
domaine, sont qualifiées d’entités. Ces classes sont généralement persistantes, c’est-àdire qu’elles survivent à l’exécution d’un cas d’utilisation particulier.
create
Configuration
Projet
manipule
Parcourir
create
utilisateur
Accueil
(from Use Case View)
Control
Page
FileWalk
lance
Ouvrir
create
EnCours
Parseur
Element
69
C- Diagrammes d’activités de navigation.
Parcourir
Configurations
btnValider
btnParcourir
btnValider
btnPersonnaliser
btnSuivant
Accueil
EnCours
btnSuivant
Presentation
btnAnnuler
btnOuvrir
btnValider
btnNouveau ou btnOuvrir
Ouvrir
Figure 23. Diagramme d’Activités de Navigation
3.3.3.4. Phase de conception :
A- Diagrammes d’interaction.
Dans le cadre de cette phase on va mieux détailler l’interaction entre les différents
objets du système, dans la phase de spécification des besoins on a élaboré un
diagramme des séquences système, il était générique (boite noire), et il n’expliquait pas
suffisamment les interactions entre les objets du système. En plus une problématique
apparaît à ce niveau, c’est la répartition des opérations sur les différentes classes.
Dans tous les cas, les diagramme d’interactions détaillés peuvent nous aider à bien
choisir les classes sur les quelles on doit affecter chaque méthode, c’est possible si on
considère que l’objet cible d’un message envoyé entre deux objets appartient
nécessairement à la classe la plus adéquate pour comporter la méthode responsable de
ce message.
70
Il est préférable d’accompagner cette phase d’un diagramme de classes de
conception complet mais indépendant des choix technologiques qui seront faits
ultérieurement. De ce fait, on suggère le diagramme de classes suivant :
Ouvrir
_
creer
_
Projet
_
manupule
_
Parcourir
_
creer
_
l'utilisateur
_
Accueil
_
FileWalk _
_
lanser
Control
_
Page
_
(from Use Case View)
_
utilise
_
Configuration
_
creer
Parseur _
_
(from Parser)
_
_
EnCours
_
utilise
Presentation
_
Element
_
_
utilise
_
Mapper
_
_
Les diagrammes des séquences détaillant les cas d’utilisations les plus intéressants :
71
A.1. Le cas d’utilisation : choisir entre les projets créés précédemment.
: utilisateur
: Acceuil
: Mapper
: Ouvrir
ouvrir
: Presentation
creer
creer
faireMapper
afficher
specifier projet
creer
creer
faireMapper
naviguer
faireMapper
Figure 24. Diagramme de Séquences : choisir entre les projets créés précédemment
72
A.2. Le cas d’utilisation : spécifier le site et lancer le « parsing »
: utilisateur
: Acceuil
: EnCours
: Mapper
: Projet
: FileWalk
: Page
: Element
specifier un nom
specifier un chemin
choisirBtnSuivant
creer
faireMapper
verifier Inexistance
[si existe]signaler l'existance
[si non]creer
faireMapper(:projet)
creer
afficher
creer
run
indiquer
creer
creer
faireMapper
creer
faireMapper
Figure 25. Diagramme de Séquences : spécifier le site et lancer le « parsing »
73
A.3. Le cas d’utilisation : fixer les options spécifiques à chaque projet
: utilisateur
: Acceuil
: Configuration
appuyer sur BtnPersonnaliser
[nom et chemin valide] creer
afficher
specefier les configurations
valider
Figure 26. Diagramme de sequences: fixer les options spécifiques à chaque projet
B. Diagramme de classes de conception.
Une première ébauche du diagramme de classes de conception a déjà été élaborée en
parallèle au diagrammes d’interaction. Il faut maintenant le compléter en précisant les
opérations privées des différentes classes. Il faut prendre en comptes les choix
techniques, comme le choix du langage de programmation et le choix des différentes
librairies utilisées.
Les spécificités du langage Java sont plus claires dans ce modèle, par exemple on a
inventé la classe (EditorKit) qui est une classe prédéfinie faisant partie du parseur
HTML de ce langage. d’autre part c’est nécessaire d’indiquer l’utilisation d’une classe
« Mapper » se chargeant de toute relation avec la base de données, les classes entités qui
constituent la base de données peuvent être détaillées en utilisant la spécialisation, mais
on va ajourner cet étape pour des raisons de lisibilité.
74
Ouvrir
creer
Projet
manupule
Parcourir
creer
l'utilisateur
Accueil
FileWalk
Control
Page
lanser
(from Use Case View)
utilise
Configuration
creer
Parseur
(from Parser)
avertir
EnCours
Presentation
Element
utilise
utilise
EditorKit
Mapper
Figure 27. Diagramme de classes de conception
Projet
nomProjet
chemin
listeAttributs
creer
Ouvrir
manupule
Parcourir
l'utilisateur
Accueil
Page
chemin
nomPage
/ type
creer
Control
FileWalk
preparerParsing()
lancerParsing()
run()
lancer
(from Use Case View)
Parseur
utilise
parse()
Configuration
creer
(from Parser)
avertir
EnCours
utilise
utilise
Mapper
Presentation
faireMapper()
EditorKit
Element
position
balise
listeAttributs
elementPere
longueur
handleXXX()
Figure 28. Diagramme de classes de conception détaillé
75
3.3.3.5. Phase d’implémentation
- Implémentation en SQL
Retournant à la construction de la base de données relationnelle, en fait, les tables de
cette base ne sont que les classes entités représentées dans le modèle de conception de
notre logiciel, mais avec les détails qu’on va aborder dans le cadre de cette section.
On commence par les trois classes principales : Projet, Page et Élément. La figure
suivant montre ces trois classes :
Projet
nomProjet
chemin
listeBalises
Page
0..n
chemin : String
nompage : String
/ type
contient
1
Element
position : Integer
balise : String
listeAttributs
elementPere : Element
longueur : Integer
include
Cette conception est suffisante pour modéliser tous les composants qui nous
intéressent.
La table Élément pose un problème : chaque élément ayant ses propres spécificités,
beaucoup de champs resteront vides ce qui rend cette table éparse. En plus, chercher un
composant nécessiterait le parcours de toute la table. Pour se réduire ce gaspillage, nous
avons crée des tables dédiées : tables, objets Multimédia, formulaires, etc.
La solution finale serait comme suit :
76
LienHypertexte
listeElementsInclus
pourvoir
0..1
Projet
nomProjet
chemin
listeBalises
1..n
Table
caption : String
listeElementsInclus : Element
0..n
includeLien
includeTable
0..n
0..1
0..n
Page
contient
chemin : String
nompage : String
0..n
1
/ type
Frame
IdFrame : String
1 0..n
0..n
0..1
0..n
Element
position : Integer
0..1
balise : String
listeAttributs
elementPere : Element
longueur : Integer
0..n
0..1
afficher
includeForm
submitVers
Formulaire
0..n
listeElementsInclus
0..1
ScriptDynamique
/ langue : String
code : String
Texte
extraitTexte : String
Multimedia
/ src : String
/ typeMultimedia : String
/ typeImage : String
commentaire
extraitCommentaire : String
Passons maintenant à la création de la base de données, selon les règles de passages
connues, on obtient le schéma relationnel suivant :
Elément (#chemin, #nomPage, position, balise, listeAttributs, longueur, #cheminPere,
#nomPagePere, #positionPere, #cheminLien, #nomPageLien, #positionLien,
#cheminTable, #nomPageTable, #positionTable, #cheminForm, #nomPageForm,
#positionForm).
Page (chemin, nomPage, type).
Frame (#chemin, #nompage, idFrame, #cheminAff, #nomPageAff).
Text (#chemin, #nompage, #position, extraitTexte).
Commentaire (#chemin, #nompage, #position, extraitCommentaire).
LienHypertexte (#chemin, #nompage, #position, listeElementsInclus, #versChemin,
77
#versNomPage, #versIdFrame).
Multimedia (#chemin, #nompage, #position, src, typeMultimedia, typeImage).
Table (#chemin, #nompage, #position, listeElementsInclus).
ScriptDynamique (#chemin, #nompage, #position, langue, code).
Formulaire (#chemin, #nompage, #position, listeElementsInclus, #subChemin,
#subNomPage, #subIdFrame).
78
Conclusion
Le présent rapport est la synthèse d’un travail effectué dans le cadre de notre projet
de fin d’études. Ce travail trouve son utilité dans un contexte de maintenance
d’applications Web existantes
Nous sommes parti d’un constat :
La dernière décennie a assisté à une explosion du nombre d’applications basées sur
le Web. Malheureusement, la technologie Web évolue à un tel rythme qu’une
application Web est très vite obsolète. Des études récentes sur le développement de
projets basés sur le Web viennent confirmer cet état chaotique (la durée de vie moyenne
d’une application Web est estimée se situer entre 3 et 4 ans). Les équipes de
développement rencontrent des problèmes majeurs pour faire face aux conditions
instables et changeantes de l’environnement Web et ils ont du mal à s’adapter au « Web
Time » et à la pression qui le caractérise.
Ce phénomène, souvent appelé « Web Speed » ou vitesse du Web, rétrécit
considérablement les délais. Pris au dépourvu, les développeurs d’applications Web
optent pour une approche ad hoc, plus simple en apparence, mais dont les retombés sont
néfastes, dés lors que la taille de l’application devient importante, et que les
conséquences d’une modification du code de l’application, deviennent imprévisibles.
Par ailleurs, l’état de l’art révèle une panoplie aussi riche que diverse de travaux
ciblés sur la conception et le développement d’applications Web. En revanche, il existe
un réel besoin en outils et techniques qui assistent le développeur lors de la maintenance
et l’évolution de ces dernières. Malgré les tentatives, les outils disponibles ne répondent
que partiellement aux attentes des développeurs. Plusieurs facteurs sont à l’origine de ce
constat. Le plus important étant, la complexité et l’effort nécessaires à la compréhension
d'un système avant toute intervention en vue de le corriger ou de le faire évoluer par de
nouveaux besoins.
En réponse à ce constat, nous proposons dans le cadre de ce mémoire un outil,
appelé WebAnalyser dont le principal objectif est d’exhiber l’architecture interne
(souvent complexe) d’une application Web en dévoilant d’une part ses différentes
79
composantes et d’autre part, les liens qui existent entre elles, afin d’en faciliter la
compréhension.
Cet outil s’inscrit dans le cadre d’un projet de rétro-conception d’applications Web
appelé RetroWeb [Ess 07]. RetroWeb est une démarche qui a été proposée par Madame
Sélima Besbes Essanaa, au sein de l’équipe ISID (Ingénierie des Systèmes
d’Information Décisionnels) du laboratoire CEDRIC (Centre d’études et de Recherche
en Informatique du Cnam) du CNAM (Conservatoire National des Arts et Métiers) à
Paris, et ce dans le cadre de sa thèse de doctorat, qui sera publiée dans les mois à venir.
RetroWeb est une solution pour la rétro-conception de sites Web peu (ou pas)
documentés. Or, avant tout processus de rétro-conception, le passage par une phase de
compréhension de l’application existante est indispensable. WebAnalyser intervient en
amont de RetroWeb pour assister le rétro-concepteur (ou plus généralement le
développeur) dans la compréhension de l’architecture interne d’une application Web.
Nous avons structuré notre rapport comme suit :
Le premier chapitre est dédié à la description des catégories d’applications Web
existantes.
Le second chapitre présente l’état de l’art sur notre problématique.
Le chapitre 3 présente notre contribution. Il est divisé en deux sections. La première
présente notre solution conceptuelle. Nous y décrivons notamment, les composants pris
en charge par notre outil ainsi que le modèle qui les supporte. La seconde section est
consacrée à la description de la réalisation de WebAnalyser. Dans cette dernière section
nous décrivons notamment l’architecture de cet outil, les choix techniques pris en
compte et enfin, le cycle de développement suivi.
L’outil que nous proposons est certes, intéressant, mais peut se prêter à des
améliorations. Celles-ci peuvent être :
-
Par le biais d’améliorations des performances des modules déjà implémentés et
la documentation du code java. En effet, ce que nous avons concrétisé est une
version zéro de l’outil WebAnalyser, qui fera certainement l’objet de plusieurs
autres stages, et l’une de nos responsabilités, est d’assurer la communication
entre les différents intervenants dans cette œuvre.
80
-
Par la prise en charge de nouveaux composants susceptibles d’intervenir dans
la construction d’une application Web. Actuellement, WebAnalyser ne
supporte que les composants les plus usuels (HTML, Scripts Java, etc.).
-
Par le biais de l’enrichissement par de nouvelles fonctionnalités. En effet,
WebAnalyser ne supporte actuellement, que des analyses syntaxiques et peut
évoluer pour supporter une analyse sémantique des composants qui s’y prêtent
(notamment les scripts).
-
Par l’amélioration de l’interface graphique, en permettant des zooms avant et
arrière sur les composants avec différents niveaux de granularité de
l’affichage.
Enfin, cette expérience a été des plus enrichissantes, dans la mesure où elle nous a
permis :
-
de concrétiser et de tester les notions acquises durant nos quatre années
d’études à l’École Supérieure de Commerce de Tunis ;
-
de flirter avec le monde de la recherche, de vivre des moments intenses de
tâtonnement et d’incertitude avant de découvrir enfin la joie de réussir à
prouver qu’une solution théorique à un problème est, concrètement et
techniquement, faisable. Nous espérons, à travers ce rapport, avoir réussi à
vous faire partager ces moments et à susciter votre intérêt pour ce travail.
Et même si nous donnons le sentiment de nous redire, cette expérience nous a
propulsé sur la voie de la maîtrise d’ouvrage. Nous la referions avec plaisir et nous
espérons qu’elle ne sera pas la dernière.
81
Bibliographie
[Aud 03] Laurent
AUDIBERT,
UML
2.0,
http://
www-lipn.univ-
paris13.fr/audibert/pages/enseignement/cours.htm
[Bar 00] Baresi L., Garzotto F., Paolini P., "From Web Sites to Web Applications: New Issues
for Conceptual Modeling", in Proceedings of the International Workshop on The
World Wide Web and Conceptual Modeling, co-located with the 19th International
Conference on Conceptual Modeling, Salt Lake City (USA), Octobre 2000
[Con 00] Conallen J., "Concevoir des applications Web avec UML", Éditions Eyrolles, 2000
[Den 98] Dennis A.R., "Lessons from Three Years of Web Development", Communications of
the ACM, 41(7), Juillet 1998, pp. 112-113
[Des 02] Desphande Y., Chandrarathna A., Ginige A., "Web Site Auditing – First Step
Towards Re-engineering", Proc. 14th International Conference on Software
Engineering and Knowledge Engineering (SEKE’02), Ischia, Italie, Juillet 2002, p.
731-737
[Isa 98a] Isakovitz T., Bieber M., Vitali F., "Web Information Systems", Communications of
the ACM, 41(7), Juillet 1998, pp. 78-80
[Kel ]
Keld H. Hansen, “Unweaving a Tangled Web With HTMLParser and Lucene”,
http://javaboutique.internet.com/
[Lan 05] Lang M., Fitzgerald B., "Hypermedia Systems Development Practices: A survey",
IEEE Software, Mars- Avril 2005
[Luc 00] Van Lancker Luc, le site (Apprendre le langage HTML), http://www....
[Mec 99] Mecca G., Merialdo P., Atzeni P., Crescenzi V., "The ARANEUS Guide to Web-Site
Development", ARANEUS Project Working Report, AWR-1-99, Mars 1999
[Pas 00]
Pascal EMMA, la rubrique des cours HTML, www.laltruiste.com
[Rag ]
Raggett
D.,
"Clean
up
your
Web
pages
with
HTML
Tidy",
http://www.W3.Org/Poeple/Raggett/Tidy/
[Ric 00a] Ricca F., Tonella P., "Web site analysis: Structure and evolution", International
Conference on Software Maintenance (ICSM ’00), Octobre 2000, p. 76-86
82
[Rol 88] Rolland C., Foucault O., Benci G., "Conception des Systèmes d’Information – La
méthode REMORA", Eyrolles, 1988
[Roq 02] Roques, P, UML - modéliser un site – commerce, (2002), Eyrolles
[Roq 06a] Roques, P, UML 2 - modéliser une application Web, (2006a), Eyrolles
[Roq 06b] Roques, P, UML 2 par la pratique (étude de cas et exercices corrigés) (5ed.), (2006b),
Eyrolles.
[Roq 03] Roques, P. &Vallée, FUML en action (2ed.), (2003), Eyrolles
[Sco ]
Scott Violet, “The Swing HTML Parser, Parsing a Netscape Navigator Bookmarks
File”, http://java.sun.com/
[Ser02]
Serge tahé, “Introduction à la programmation Web en Java”,Septembre 2002
[Tak 97] Takahashi K., Liang E., "Analysis and Design of Web Based Information Systems",
Proceedings of the 6th International World Wide Web Conference (WWW6), Santa
Clara, California, USA, Avril 1997
[Til 01]
Tilley S., Huang S., "Evaluating the Reverse Engineering Capabilities of Web Tools
for Understanding Site Content and Structure: A Case Study", Proceedings of the
23rd International Conference on Software Engineering (ICSE 2001), Mai 2001, p.
514-523,
[Tra 05] Porfirio Tramontana, « Reverse Engineering of Web Applications », Ph. D. Thesis
83