JDN
Développeurs : Dans l'introduction de votre livre,
vous décrivez la POA plus comme une "amélioration" de
la programmation orientée objets (POO), plutôt
qu'un remplacement pur de cette dernière. Pouvez-vous
décrire brièvement ce qu'apporte la POA ?
R. Pawlak - J.-P. Retaillé - L. Seinturier
: La POA répond au besoin de mieux maîtriser les
coûts et la maintenance des applications fondées sur
la POO en améliorant la séparation et l'intégration
des préoccupations au sein des applications. Un premier
niveau de séparation et d'intégration consiste à traiter
les problématiques techniques et les problématiques
métiers indépendamment puis de les intégrer à l'aide
de frameworks le plus souvent centrés sur des conteneurs
de composants. Ce premier niveau n'est adressé que partiellement
par les solutions actuelles comme les EJB tant du point
de vue du périmètre fonctionnel couvert que du point
de vue de l'étanchéité de la séparation. De plus, la
lourdeur de mise en place de ces solutions et leur complexité
rend aussi leur accès difficile aux projets de taille
modeste.
Quels sont alors les besoins
auxquels la POA répond ?
En proposant des mécanismes de séparation des préoccupations
génériques et programmables, la POA démocratise une
nouvelle dimension de modularisation des applications.
Elle permet de modulariser sous formes d'aspects tout
type de problématique transversale à une application
et permet d'atteindre des niveaux de réutilisation supérieurs
à celui des approches par objets ou par composants.
Les bibliothèques et frameworks actuels seront les premiers
bénéficiaires de la POA car elle leur permettra de s'intégrer
aux applications utilisatrices de manière encore moins
intrusive, mais aussi et surtout d'étendre leur périmètre
fonctionnel à d'autres types de préoccupations pour
l'instant peu réceptives aux solutions d'intégration
classiques.
La
POO a été mise au point dans les années 1960 et semble
enfin acceptée par la plupart des développeurs. La POA
étant conçue "sur" la POO, pensez-vous que son adoption
sera plus rapide ? Nécessitera-t-elle de gros changements
d'habitudes ?
Nous pensons que l'adoption de le POA sera indéniablement
plus rapide que celle de la POO. Les premiers travaux
de recherche sur la POA datent du milieu des années
90, et on commence à en parler en dehors du monde de
la recherche seulement depuis 2-3 ans. Sur cette période,
plusieurs acteurs importants du monde informatique comme
IBM ou BEA ont clairement affiché leur intérêt pour
cette technologie et ont contribué au développement
d'outils pour la POA. Contrairement à ce qui s'est passé
avec le passage à la POO, le passage à la POA peut se
faire en douceur.
|
|
L'utilisation de la POA nécessite un ticket
d'entrée nettement moins élevé que celui exigé
pour la POO" |
|
La POA reste donc proche
de la POO...
Avec la POA, les applications continuent à être construites
en termes de classes : on leur ajoute un ou plusieurs
aspects qui viennent enrichir leurs fonctionnalités
techniques et/ou métier. Il est ainsi facile de choisir
les fonctionnalités à implémenter sous forme d'aspects
et de se limiter à un nombre restreint d'aspects stratégiques
(sécurité, contrôle de l'intégrité des données, etc.).
De ce fait, et une fois les concepts nouveaux introduits
par la POA (aspect, coupe, point de jonction, code advice)
maîtrisés, il n'y aura pas de changement majeur dans
les habitudes de développements. Ainsi, l'utilisation
de la POA nécessite un ticket d'entrée nettement moins
élevé que celui exigé pour la programmation orientée
objet qui impliquait une refonte totale des applications
existantes pour bénéficier de ses avancées technologiques.
Les méthodes de développement
actuelles, telles que UML, sont-elles compatibles avec
la POA ?
Dans le cadre de la mouvance MDA, UML et les outils
qui la supportent sont désormais suffisamment ouverts
et extensibles pour pouvoir intégrer la POA. Plusieurs
équipes de recherche ont montré qu'il est possible de
définir des profils UML pour la conception d'une application
comprenant des classes et des aspects. Ces profils se
fondent essentiellement sur des stéréotypes nouveaux
pour l'expression des aspects et des coupes et peuvent
être implantés dans des outils MDA tels que l'atelier
Objecteering de la société Softeam. Nous pensons que
la POA et la MDA peuvent s'entendre dans une symbiose
extrêmement efficace. La POA permet en effet à la MDA
de simplifier l'écriture des transformations des modèles
vers les implémentations (et inversement), alors que
la MDA permet à la POA de remonter certains outils de
séparation et d'intégration des préoccupations au niveau
de l'analyse et de la conception. Les prototypes existants
doivent cependant encore montrer leur applicabilité
dans le cas d'études de cas significatives issues de
l'industrie.
Des applications concrètes
ont-elles déjà vu le jour ?
L'atelier de développement UMLAF (UML Aspect Factory)
fait partie des exemples concrets qui montrent que la
POA et UML peuvent être mis en oeuvre conjointement.
UMLAF est construit autour du framework JAC
et est proposé par la société AOPSYS. Il offre aux développeurs
la possibilité d'exprimer graphiquement des diagrammes
d'analyse UML et d'exprimer la conception de l'application
à l'aide de configurations d'aspects. L'application
générée est directement exécutable, réduisant ainsi
l'écriture de code Java et les risques d'erreurs de
programmation au minimum.
AspectJ/Eclipse est de plus en plus souvent utilisé
comme outil pour améliorer la maintenance et le contrôle
des applications via l'intégration d'aspects de trace
ou de vérification de contraintes. Les applications
entièrement orientées aspect sont encore rares mais
on peut noter quelques projets Internet et Intranet
de taille conséquente menés par la société AOPSYS sous
l'environnement JAC/UMLAF (entièrement POA). Pour les
clients qui ont optés pour la POA avec AOPSYS, les applications
ont été développées et validées avec succès et sont
actuellement pour les plus avancées en phase de mise
en production.
Pensez-vous qu'il y aura
une "révolution POA" comme la POO a pu en être une ?
Nous préférons parler d'évolution plutôt que de révolution
car la POA ne remet pas en cause les autres paradigmes
de programmation. Elle s'insère plutôt dans la révolution
commencée avec les premiers modèles de composants dont
l'objectif de favoriser l'intégration et la réutilisation
par rapport au développement spécifique.
En fait, la POA propose un modèle générique de séparation
des préoccupations, problématique déjà adressée de manière
partielle et spécifique par les systèmes à base de composants
comme les EJB dont l'objectif était de séparer les deux
préoccupations que sont les problématiques techniques
et métiers des composants d'entreprise.
Quel est l'atout de ce
modèle générique ?
En offrant un modèle générique de la séparation des
préoccupations, la POA favorise l'émergence de nouveaux
conteneurs de composants beaucoup plus légers et flexibles
que ceux disponibles actuellement. Ces nouveaux conteneurs
pourront bénéficier d'une offre d'aspects très riche
leur permettant de s'adapter facilement aux besoins
des utilisateurs contrairement aux serveurs d'applications
à l'approche beaucoup plus monolithique. Par ailleurs,
les utilisateurs ne trouvant pas sur le marché d'aspect
adapté à leur besoin auront la possibilité de les développer
eux-mêmes de la même façon qu'ils développent des composants
actuellement.
Mis à part AspectJ, existe-t-il
d'autres langages qu'un développeur puisse aujourd'hui
utiliser pour "faire la POA" ?
Les développeurs peuvent tout simplement utiliser le
langage Java. AspectJ a introduit de nouveaux mots-clés
pour couvrir les différents concepts de la POA. Cependant,
ces concepts peuvent être couverts sans étendre le langage
Java. C'est la position adoptée par plusieurs frameworks
comme JAC, JBoss AOP ou AspectWerkz. Au lieu de définir
de nouveaux mots-clés, ils fournissent une API permettant
de manipuler ces concepts de manière efficace.
Pourquoi avez-vous senti
que c'était le moment de faire un livre sur la POA ?
La POA est encore une technologie jeune puisque les
premiers outils permettant de l'utiliser concrètement
sont apparus à la fin des années 90 avec AspectJ et
JAC.
Cependant, ses principes fondateurs sont maintenant
bien formalisés et sortent du cadre de la recherche
pour celui des applications industrielles. Les principaux
éditeurs du monde J2EE ne s'y trompent pas et investissent
autour de la POA pour rendre Java plus efficace. Le
monde .Net, bien qu'ayant un léger retard sur le sujet,
commence aussi à mettre au point des outils de POA (on
citera le projet AspectDNG par exemple). L'adhésion
de l'industrie du logiciel à ce nouveau paradigme ainsi
qu'un intérêt certain de la part des développeurs nous
ont encouragés à écrire ce livre.
Et pourquoi se "limiter"
à Java/J2EE ?
Plusieurs livres américains sur l'outil AspectJ existant
déjà, il nous a semblé opportun d'avoir un ouvrage avec
un spectre plus large en couvrant les frameworks de
POA 100% Java et les problématiques des applications
d'entreprises fondées sur J2EE. Notre livre n'est d'ailleurs
en aucun cas centré sur les bonnes pratiques à utiliser
dans tel ou tel outil ou langage POA, mais plutôt sur
une analyse précise des problématiques couramment rencontrées
par les architectes et les développeurs et qui peuvent
être résolues de manière plus efficace avec la POA,
exemples à l'appui.
Nous espérons ainsi faire profiter nos lecteurs d'une
vision globale de ce nouveau paradigme et d'un guide
de mise en oeuvre de la POA sur des problématiques concrètes.
|