Une des limites des paradigmes de programmation tarditionnels (programmation impérative,
par objets, ...) est la difficulté d'implanter des applications complexes. Le développement
de telles applications implique l'implantation conjointe des fonctions
(services) qu'elles proposent et des propriétés non-fonctionnelles (propriétés
d'infrastructure). Par exemple dans une application de commerce électronique,
les fonctions que représentent la recherche d'un produit et la passation de
commande dans une application doivent être implantées en prenant en compte les
propriétés non-fonctionnelles que sont la communication distante, la
synchronisation, la persistance, ...
Ces différentes parties de l'applications (services, propriétés
d'infrastructure) se trouvent intimement enchevêtrées dans le code de
l'application. D'où une complexité de développement source d'erreurs (bugs)
et coûteuse en temps de développement. Le code résultant est difficile à
comprendre, ce qui constitue un obstacle à la bonne maintenance et à l'évolution
des applications. A cela s'ajoute le problème d'anomalie d'héritage qui limite
les possibilités de réutilisation.
Programmation par aspects
La programmation par aspects [1, 2] est un nouveau paradigme dont le but est de
simplifier le développement, la maintenance et l'évolution d'applications
complexes. Cette simplification est obtenue en fractionnant les applications en
modules complémentaires développés séparément les uns des autres. Chaque
module constitue la définition de manière isolée d'une facette particulière
(un aspect) de l'application. Un outil permet l'assemblage (on parle de tissage)
automatique des aspects pour produire une application.
Dans l'exemple précédent, l'application de commerce électronique serait
structurée en quatre aspects : les fonctions de l'application seraient définis
dans un module unique représentant l'aspect de base, alors que les aspects
communication distante, synchronisation et persistance seraient définis chacun
dans un module différent. Ainsi, les développeurs peuvent se concentrer sur un
aspect de l'application à la fois. Les aspects décrits dans des modules
distincts sont faiblement couplés. Dès lors, il est possible d'en modifier
certains sans toucher aux autres et donc de limiter le risque d'erreur. De même,
il est possible d'ajouter a posteriori de nouveaux aspects.
Réflexion
La réflexion est la capacité d'un système à raisonner et à agir sur lui-même
[3]. Dans le cadre des langages de programmation, la réflexion se traduit par
la possibilité d'observer et de modifier dynamiquement un programme ainsi que
sa manière de s'exécuter. Par exemple, la réflexion permet de retrouver à
l'exécution l'ensemble des méthodes d'une classe ou de modifier la sémantique
de l'envoi de message.
Les intérêts de la réflexion sont multiples. Elle simplifie la construction
d'outils de développement (navigateurs, débogueurs...). Elle offre la
possibilité d'étendre et d'adapter le langage de programmation pour mieux répondre
à un problème donné (changement du modèle d'héritage, introduction du
concept d'acteur dans un langage à classes, ...). De plus, un système réflexif
peut se modifier pour s'adapter aux changements qui peuvent affecter son
environnement d'exécution (évolution de la charge d'un réseau, connexion ou déconnexion
de matériels...).
Un autre intérêt de la réflexion est qu'elle offre différents niveaux de
programmation. En effet, à l'aide d'un langage réflexif, il est possible non
seulement de décrire les tâches qu'un programme doit réaliser, mais également
la manière de réaliser ces tâches. Ces deux descriptions sont découplées
car introduites à des niveaux différents. Les tâches sont définies au niveau
du programme. Alors que la manière de les réaliser est définie au niveau de
l'interprète. Cette séparation est particulièrement importante car elle peut
être exploitée comme support de la programmation par aspects [4].
Objectifs du stage
Ce stage de DEA s'inscrit dans le cadre de nos travaux sur la programmation
par aspects pour la construction de systèmes répartis. L'objectif visé
est d'identifier les différents aspects liés aux services web et de proposer
une implantation. Ces différents aspects doivent être isolés et décrits sous
forme d'une bibliothèque réutilisable. Le but étant de fournir un cadre pour
développer les applications en se focalisant uniquement sur les services
qu'elles rendent (le côté métier). Ces services seront rendus accessibles via
le web en intégrant la bibliothèque précédement définie.
L'un des problèmes majeurs à résoudre réside dans les conflits évenutels
qui peuvent apparaitre entre les aspects. Ces éventuels conflits doivent être
identifiés et résolus si possible de manière automatique de manière à
automatiser l'intégration de la bibliothèque d'aspects.
Ce travail s'appuyera sur nos travaux en cours et notamment notre plateforme réflexive
MetaclassTalk [5] qui sert de support à la programmation par aspects.
Références bibliographiques
"Aspect-Oriented Programming", G. Kiczales et al. Actes de la
conférence ECOOP 2001.
"Le point sur la programmation par aspects", N. Bouraqadi, T.
Ledoux. Revue : Technique et Science Informatique (TSI), 2001.
"Reflection and Semantics in Lisp", B. Smith. Actes de la conférence
POPL'84.
"Un cadre réflexif pour la programmation par aspects", N.
Bouraqadi. Actes de la conférence LMO'99.