Programmation. orientée aspect pour Java/J2EE. Renaud Pawlak. Jean-Philippe Retaillé. Lionel Seinturier. Groupe Eyrolles, 2004, ISBN :

Transcription

1 Programmation orientée aspect pour Java/J2EE Renaud Pawlak Jean-Philippe Retaillé Lionel Seinturier Groupe Eyrolles, 2004, ISBN :

2 9 Qualité de service des applications et POA La puissance des ordinateurs suivant la célèbre loi de Moore, les limites imposées aux logiciels sont sans cesse repoussées et les applications de plus en plus riches et complexes. Cette complexité doit être gérée, car elle peut entraîner des dysfonctionnements nuisibles à la qualité de service des applications. Pour gérer la complexité des applications, différentes techniques ont été mises au point. Ce chapitre introduit les trois techniques complémentaires suivantes, dont l implémentation bénéficie particulièrement des avancées technologiques de la programmation orientée aspect : Le design par contrats, qui est une méthode de développement permettant de formaliser les contraintes liées à l utilisation d une classe. Les principes du design par contrats sont peu présents dans les langages de programmation actuels mais peuvent être facilement implémentés avec les outils de la POA. L analyse de couverture, qui vérifie l exhaustivité d une campagne de tests sur une application, et les tests de non-régression, qui vérifient que les fonctions non concernées par un changement de l application ont toujours un fonctionnement conforme. Ces deux types de tests bénéficient de la capacité de la POA à instrumenter le code pour surveiller son exécution. L administration et la supervision des applications, qui permettent de suivre le fonctionnement de ces dernières en production et d intervenir en cas d incident. Ces deux fonctions peuvent être aisément mises en place de manière transparente pour l application grâce à la POA.

3 220 Applications de la POA PARTIE III Le design par contrats Le design par contrats est une méthode de développement consistant à formaliser le cadre d utilisation des composants d une application. Pour cela, des contraintes sont spécifiées et doivent être vérifiées par les composants afin de garantir un comportement conforme à leurs spécifications. Les concepts du design par contrats ont été popularisés par Bertrand Meyer dans son ouvrage Object-Oriented Software Construction, 2nd Edition (Prentice Hall, 1997). Ils sont utilisés dans certains langages de programmation, comme le célèbre Eiffel, créé en 1985 par la société ISE, dont fait partie B. Meyer. La POA fournit les techniques de base permettant d implémenter cette méthode de développement de manière simple et efficace. Avant de détailler l implémentation du design par contrats à l aide de la POA, nous allons effectuer une présentation synthétique de ses grands principes et de leur support par Java. Principes fondateurs du design par contrats Les mécanismes de contrôle de cohérence de la plupart des langages, tel le typage fort des variables, ne sont pas suffisants pour matérialiser les contraintes liées à la classe et à chacune de ses méthodes. La cohérence de l état d une instance de classe ainsi que l appel d une méthode ou de son résultat nécessitent des outils plus évolués, comme les contrats. En mettant en place des contrats dans vos applications, vous bénéficiez des avantages suivants : Meilleure efficacité des tests et du débogage. Les contrats permettent de définir de manière beaucoup plus stricte les conditions d exécution des différentes classes composant une application. Meilleure documentation du code et réutilisation des composants. Les contrats sont spécifiés clairement dans le code des composants et donc facilement lisibles par les développeurs. La réutilisation est facilitée car les contraintes liées à un composant sont exposées de manière explicite. Meilleure gestion des erreurs. En cas de non-respect d un contrat, plusieurs stratégies peuvent être mises en place afin de corriger ou contourner le problème. L utilisation de contrats dans les développements est donc un moyen de réduire les bogues en facilitant leur détection et en améliorant l intégration des multiples classes développées par des équipes différentes et utilisées au sein de un ou plusieurs logiciels. Les langages qui supportent les contrats permettent d activer ou de désactiver ces derniers lors de la compilation ou de l exécution de l application. La prise en compte des contrats peut en effet consommer beaucoup de ressources et diminuer la performance du logiciel. Du fait de la possibilité de court-circuiter les contrats, il est important de les utiliser à bon escient, c est-à-dire en tant qu outils de test et non de production. Précisons qu ils ne sont pas destinés à remplacer tous les tests, et surtout pas ceux destinés à la sécurité.

4 Qualité de service des applications et POA CHAPITRE Éléments d un contrat Que ce soit en programmation ou en droit, un contrat comporte plusieurs éléments permettant de formaliser un échange entre une ou plusieurs entités. Un contrat engage au moins deux parties contractantes. Dans le domaine qui nous intéresse, les contractants sont l utilisateur un composant quelconque de l application et le fournisseur une classe et ses instances. Un contrat comporte en outre un objet, lequel détermine la nature de l échange, par exemple une fourniture de service. Dans ce cas, un composant quelconque de l application peut donc bénéficier des services offerts par une classe et ses instances au travers de leurs méthodes publiques. La définition des contractants et de l objet du contrat ne se suffit pas à elle-même. Elle doit être assortie d obligations s appliquant aux différentes parties du contrat. Concernant une méthode publique, il s agit pour l utilisateur le composant appelant de respecter certaines contraintes portant sur les paramètres d entrée. De son côté, le fournisseur la méthode publique doit respecter certaines contraintes sur les paramètres de sortie, ainsi que sur la valeur de retour s il s agit d une fonction. Les obligations d un contrat au sens logiciel du terme sont matérialisées à l aide d assertions. Définition Assertion. Une assertion exprime une condition booléenne devant être remplie à un moment défini. Si le résultat de l assertion est vrai, la condition est remplie. S il est faux, la condition n est pas remplie, et il y a litige. Une assertion peut être utilisée à n importe quel endroit du code. Par exemple, si nous devons effectuer une division dont le dénominateur est une variable, nous pouvons définir une assertion avant cette opération afin de vérifier que la variable en question est non nulle. Une condition doit être littérale. L appel de méthodes au sein d une assertion peut avoir des effets de bord néfastes pour leur contrôle et la fiabilité de l application. L assertion est une forme générique. Elle peut être spécialisée pour les classes et les méthodes. Il existe quatre assertions spéciales, la précondition, la postcondition, l invariant de classe et l invariant interne. Définition Précondition. Une précondition est une assertion devant être vérifiée à l appel d une méthode. Elle doit être remplie pour permettre l exécution de celle-ci. La précondition est une obligation portant sur l utilisateur de la méthode. Pour illustrer l utilisation de la précondition, prenons l exemple de la racine carrée. Supposons que nous ayons développé une méthode sqrt (square root, ou racine carrée) prenant un paramètre réel et renvoyant comme résultat sa racine carrée.

5 222 Applications de la POA PARTIE III La précondition évidente s appliquant à cette méthode est la suivante : Précondition : parametre >= 0 Tout appel à cette méthode est voué à l échec si le paramètre est négatif. La précondition permet de traiter plus ou moins finement cet échec en fonction des facilités offertes par l implémentation des contrats dans le langage. Définition Postcondition. Une postcondition est une assertion devant être vérifiée à la fin de l exécution d une méthode. Elle permet de vérifier que la méthode s est exécutée correctement selon les termes de la postcondition. La postcondition porte sur le fournisseur de la méthode. Un exemple de postcondition peut être fourni par la méthode sqrt, qui ne peut renvoyer de résultat négatif. La postcondition de la méthode sqrt est la suivante : Postcondition : resultat >= 0 Tout résultat ne respectant pas cette postcondition indique que la méthode sqrt n a pas été correctement implémentée. Définition Invariant de classe. Un invariant de classe est une assertion devant être vérifiée par l état d une classe. Il garantit que la classe est dans un état cohérent. Cette obligation porte sur le fournisseur, en l occurrence la classe. Pour illustrer l utilisation d un invariant de classe, supposons que nous ayons défini une classe générique modélisant une figure géométrique quelconque en deux dimensions. Cette figure peut être définie sous la forme d un ensemble de points représentant les sommets, ensemble stocké dans un attribut de type tableau de points. Cette classe générique peut ensuite être dérivée en des classes représentant des figures spécifiques, comme le triangle ou le carré, ayant un nombre de sommet fixe. Pour chacune de ces classes spécifiques, un invariant de classe peut être défini afin de vérifier que le nombre de sommet est conforme à la figure. Pour le triangle, nous avons l invariant de classe suivant : Invariant de classe : nombre de sommets == 3 Grâce à cet invariant, toute manipulation frauduleuse de l ensemble des sommets faisant varier leur nombre est détectée pour le triangle.

6 Qualité de service des applications et POA CHAPITRE Définition Invariant interne. Un invariant interne est une assertion devant être vérifiée dans le corps d une méthode. Il garantit que le traitement se comporte de manière correcte. Cette obligation porte sur le fournisseur, en l occurrence la méthode. Supposons que nous ayons développé une méthode de simulation d emprunt bancaire. Le calcul du montant total des intérêts en fonction des taux du marché non passés en paramètres à la méthode, donc non vérifiables par une précondition au sein de cette méthode peut être contrôlé par un invariant interne. Les intérêts ne pouvant être négatifs, nous avons : Invariant interne : montant total des intérêts >= 0 Règlement des litiges Si une obligation n est pas respectée, il y a litige. Deux grandes stratégies peuvent être appliquées pour le régler : l arbitrage (clause compromissoire) et la rupture (clauses de résiliation et résolutoire). Ces trois clauses peuvent s appliquer de la manière suivante : Clause compromissoire. En cas de non-respect d une obligation du contrat, une ou plusieurs nouvelles tentatives d appel sont effectuées (recherche d un compromis, d où l adjectif compromissoire) en modifiant ou non les paramètres (l erreur peut provenir d une source indépendante des paramètres). Si l obligation n est toujours pas respectée à l issue de ces tentatives, une erreur est signalée. Clause de résiliation. En cas de non-respect d une obligation, le traitement s arrête sur cette erreur sans action particulière. C est le même principe qu une résiliation d abonnement à un magazine : une fois la lettre de résiliation envoyée, vous n avez pas à retourner les exemplaires reçus après rupture du contrat d abonnement. Clause résolutoire. En cas de non-respect d une obligation, le traitement s arrête après avoir mené un certain de nombre de tâches de nettoyage destinées à remettre le système dans son état initial. Par exemple, cela peut être un retour arrière (rollback) sur des transactions avec une base de données. C est le même principe qu un achat d objet par correspondance : s il ne vous convient pas, vous le renvoyez (retour à l état initial) pour vous faire rembourser (fin de l exécution). Héritage des contrats Un des mécanismes clés de la programmation orientée objet est l héritage. Ce mécanisme permet à une classe fille d hériter des attributs et des méthodes publiques ou protégées de sa classe mère. En toute logique, l héritage concerne aussi les obligations portant sur la classe mère et ses méthodes. Bien entendu, les classes filles disposent d une certaine latitude pour modifier les contrats hérités :

7 224 Applications de la POA PARTIE III Pour les préconditions, les classes filles ont la possibilité de les garder identiques ou de les rendre moins restrictives. Pour les postconditions, les classes filles ne peuvent que les garder identiques ou les rendre plus restrictives. Pour les invariants de classe, les invariants de la classe mère font automatiquement partie des invariants des classes filles. Pour les invariants internes hérités, ils ne sont conservés que dans la mesure où la classe fille ne redéfinit pas les méthodes sur lesquelles ils portent. Grâce à ces principes, nous pouvons garantir qu une classe fille offre au minimum le même niveau de service que sa classe mère. Il n est pas possible de créer une version appauvrie de la classe mère. Cette garantie est fondamentale dans tout langage de programmation orientée objet. Elle trouve tout son intérêt dans le polymorphisme d héritage, c est-à-dire la capacité d une classe fille à redéfinir les méthodes de sa classe mère. Une méthode donnée prenant en paramètre un objet de type ClasseMere peut être appelée avec un objet de type Classe- Fille, ClasseFille héritant de ClasseMere. L exécution de la méthode en question repose sur plusieurs hypothèses, dont certaines sont liées au contrat attaché à ClasseMere. Il faut donc que ClasseFille fournisse au moins le même niveau de service que ClasseMere pour garantir la bonne manipulation de ses instances par la méthode. Java et les contrats Suite à la JSR (Java Specification Request) n 41 (A Simple Assertion Facility), la version 1.4 de J2SE a introduit un support limité des contrats, similaire à celui offert par le langage C avec la macro assert. Le nouveau mot-clé assert a été introduit dans le langage Java à cette fin. L instruction assert accepte deux formes : assert condition ; assert condition : valeur. Sous sa première forme, assert se comporte de la manière suivante : Si la condition booléenne renvoie vrai, l exécution du programme se poursuit normalement. Si la condition booléenne renvoie faux, une erreur de type java.lang.assertionerror dérivée de java.lang.error est générée. Sous sa seconde forme, assert se comporte de la manière suivante : Si la condition booléenne renvoie vrai, l exécution du programme se poursuit normalement.

8 Qualité de service des applications et POA CHAPITRE Si la condition booléenne renvoie faux, une erreur de type java.lang.assertionerror est générée en passant valeur au constructeur. valeur doit être de type string et peut être une constante ou une fonction renvoyant un objet convertissable en string. L utilisation d une sous-classe de java.lang.error et non de java.lang.runtimeexception n est pas innocente. Cela signifie que le programme a rencontré une erreur critique non récupérable et qu il doit se terminer. Par ailleurs, cette instruction n est utilisable que dans le corps d une méthode ou d un bloc statique. Concernant l exécution d un programme doté de contrats, deux nouveaux paramètres sont apparus au niveau de la JVM pour activer ou désactiver les assertions : enableassertions et disableassertions. La portée de ces paramètres peut être globale ou de niveau package ou classe. La nouvelle fonctionnalité apportée par J2SE 1.4 est en fait une version simplifiée des contrats. Les préconditions, postconditions et invariants n étant pas supportés nativement par le langage, il est nécessaire de placer les instructions assert de manière judicieuse pour obtenir ces fonctionnalités. Cela peut se révéler fastidieux, notamment pour les postconditions, pour lesquelles il est nécessaire de placer des instructions assert à toutes les sorties possibles d une méthode. Implémentation des contrats avec la POA La programmation orientée aspect fournit des techniques qui facilitent l implémentation des contrats dans le langage Java. Comme expliqué précédemment, le JDK 1.4 ne fournit pas de notions de précondition, de postcondition ou d invariant de classe. La POA montre une facette de sa puissance en fournissant de manière simple ces trois fonctionnalités aux applications. Pour illustrer l implémentation de ces fonctionnalités par la POA, nous utilisons dans ce chapitre le framework AOP de JBoss, qui permet d activer et de désactiver les assertions sans avoir à recompiler le code source, une étape obligatoire avec AspectJ. Les exemples fournis sont aisément transposables sur le framework JAC. Implémentation des préconditions Les préconditions sont les assertions les plus simples à implémenter car leur point d entrée, c est-à-dire l appel à la méthode sur laquelle elles portent, est unique et que leur calcul ne dépend que des paramètres passés à la méthode et de l état de l instance de leur classe. Elles n ont généralement pas à prendre en compte d éventuels comportements erratiques autres que ceux liés à leur propre calcul.

9 226 Applications de la POA PARTIE III Le code Java suivant donne l implémentation Java de la méthode racine carrée (sqrt) et le programme réalisant plusieurs appels à cette méthode pour la tester : package aop.contracts.preconditions; public class PreConditionExample { public double sqrt (double p) { return Math.sqrt(p); public static void main(string[] args) { PreConditionExample t = new PreConditionExample(); System.out.println("racine carrée de 4 : "+t.sqrt(4)); System.out.println("racine carrée de 0 : "+t.sqrt(0)); System.out.println( "racine carrée de -4 : "+t.sqrt(-4)); System.out.println("racine carrée de 9 : "+t.sqrt (9)); L implémentation de la méthode sqrt n est qu un appel à la méthode de même signature de la classe java.lang.math (repère ). La méthode main réalise plusieurs appels à la méthode sqrt, dont le troisième est incorrect du point de vue de la précondition «p supérieur ou égal à 0» associée à sqrt (repère ). Le dernier appel (repère ) est effectué à titre de contrôle. Si nous exécutons la méthode main sans mise en place de la précondition, nous obtenons le résultat suivant : racine carrée de 4 : 2.0 racine carrée de 0 : 0.0 racine carrée de -4 : NaN racine carrée de 9 : 3.0 Nous constatons qu aucune exception n est générée par le passage d un paramètre négatif lors de l appel (repère ). La valeur renvoyée par la méthode java.lang.math.sqrt(double) est java.lang.double.nan pour signaler que le résultat n est pas un nombre (NaN = Not a Number). Programmation de la précondition La précondition se matérialise au travers d un intercepteur correspondant à la notion de code advice dans le framework JBoss AOP. Le code source suivant montre une implémentation simple de la précondition attachée à la méthode sqrt :

10 Qualité de service des applications et POA CHAPITRE package aop.contracts.preconditions; import java.lang.reflect.method; import org.jboss.aop.interceptor; import org.jboss.aop.invocation; import org.jboss.aop.invocationresponse; import org.jboss.aop.invocationtype; import org.jboss.aop.methodinvocation; public class PreConditionInterceptor implements Interceptor { public String getname() { return "PreConditionInterceptor"; public InvocationResponse invoke(invocation invocation) throws Throwable { if (invocation.gettype() == InvocationType.METHOD) { MethodInvocation methodinvocation = (MethodInvocation)invocation; Method method = methodinvocation.method; if ("sqrt".equals(method.getname())) { Double parameter = (Double) methodinvocation.arguments[0]; if (parameter.doublevalue() < 0) { throw new Error( "Litige sur la précondition"); InvocationResponse rsp = invocation.invokenext(); return rsp; L implémentation de la précondition sous la forme d un intercepteur ne pose pas de problème particulier. Il suffit de créer une classe implémentant les deux méthodes de l interface org.jboss.aop.interceptor, à savoir la méthode getname, qui renvoie le nom de l intercepteur, et la méthode invoke, qui constitue le code advice à proprement parler. Le fonctionnement de la méthode invoke est le suivant : 1. Nous vérifions le type d invocation : InvocationType.CONSTRUCTOR, METHOD, FIELD_READ ou FIELD_WRITE (repère ). Dans notre cas, nous ne nous intéressons qu aux invocations de méthodes. 2. Si le nom de la méthode invoquée est sqrt, nous contrôlons la précondition (repère ). 3. L attribut arguments de l objet methodinvocation (repère ) nous permet de récupérer la valeur du paramètre passé en argument à sqrt et de vérifier s il est négatif au non.

11 228 Applications de la POA PARTIE III 4. Si la valeur du paramètre est négative, nous créons un message d erreur et générons une erreur (java.lang.error) pour indiquer au programme qu une anomalie irrécupérable s est produite (repère ). Paramétrage de la précondition Pour terminer la mise en place de la précondition, il est nécessaire de modifier le fichier jboss-aop.xml en déclarant une nouvelle coupe et l intercepteur associé. Pour notre exemple, le fichier jboss-aop.xml doit comporter les tags suivants : <interceptor-pointcut methodfilter="all" fieldfilter="none" constructorfilter="none" class="aop.contracts.preconditions.preconditionexample"> <interceptors> <interceptor class="aop.contracts.preconditions.preconditioninterceptor"/> </interceptors> </interceptor-pointcut> Ces tags permettent de définir la classe sur laquelle porte la coupe (repère ) et l intercepteur appliqué (repère ). Les paramètres methodfilter, fieldfilter et constructorfilter permettent d affiner la portée de la coupe : dans le cas présent, nous n instrumentons que les méthodes. Ce paramétrage rend moins utile le premier if de la méthode invoke de l intercepteur PreConditionInterceptor (repère dans le code de PreConditionInterceptor). En effet, cette première condition vérifie que l appel à invoke concerne une méthode et non un attribut ou un constructeur, ce qui est redondant avec le paramétrage du tag interceptor-pointcut dans jboss-aop.xml (methodfilter="all" fieldfilter="none" constructorfilter="none"). Cette condition a été conservée pour plus de sécurité en cas d élargissement de la portée de la coupe dans jboss-aop.xml, par exemple du fait d une modification du paramètre constructorfilter du tag interceptor-pointcut afin de faire prendre en compte par l intercepteur les appels aux constructeurs. Résultat de l exécution Une fois l intercepteur compilé et le fichier jboss-aop.xml et la JVM correctement paramétrés, l exécution du programme donne le résultat suivant : racine carrée de 4 : 2.0 racine carrée de 0 : 0.0 java.lang.error: Litige sur la précondition. [ ] Exception in thread "main"

12 Qualité de service des applications et POA CHAPITRE Nous constatons que l appel erroné à sqrt génère une erreur ne permettant pas au programme de poursuivre son exécution, contrairement à ce qui se produit avec la version sans précondition. Implémentation des postconditions Les postconditions sont un peu plus complexes à implémenter que les préconditions car elles doivent généralement prendre en compte les valeurs suivantes : valeur de retour de la méthode appelée ; valeurs avant et après appel des paramètres ainsi que des attributs de la classe. Nous allons illustrer la prise en charge des postconditions par la POA au travers de deux exemples. Le premier est toujours la méthode sqrt, qui doit systématiquement renvoyer un résultat positif ou nul. Il illustre la récupération de la valeur de retour de la méthode pour tester la postcondition. Le second est la méthode increment(int parametre), qui renvoie un entier dont la valeur est égale à parametre+1. Pour les besoins de la démonstration, le programme utilisé pour illustrer la précondition a été légèrement modifié : package aop.contracts.postconditions; public class PostConditionExample1 { public double sqrt(double p) { if (p==0) { return -1; return Math.sqrt(p); public static void main(string[] args) { PostConditionExample1 t = new PostConditionExample1(); System.out.println("racine carrée de 4 : "+t.sqrt(4)); System.out.println("racine carrée de 0 : "+t.sqrt(0)); System.out.println("racine carrée de 9 : "+t.sqrt(9)); Nous avons introduit un bloc conditionnel renvoyant un résultat erroné (-1) si le paramètre p est égal à 0 (repère ). En passant cette valeur à sqrt, nous pouvons tester la postcondition développée plus loin. Le second programme présente une version de la méthode increment contenant une erreur classique de programmation : package aop.contracts.postconditions; public class PostConditionExample2 {

13 230 Applications de la POA PARTIE III public int increment(int p) { return p++; public static void main(string[] args) { PostConditionExample2 t = new PostConditionExample2(); System.out.println("incrémente 1 : "+t.increment(1)); L instruction devrait être return ++p; (incrémente p et renvoie sa valeur). Programmation des postconditions Pour la méthode sqrt, la postcondition implémentée sous forme d intercepteur est la suivante : package aop.contracts.postconditions; import java.lang.reflect.method; import org.jboss.aop.interceptor; import org.jboss.aop.invocation; import org.jboss.aop.invocationresponse; import org.jboss.aop.invocationtype; import org.jboss.aop.methodinvocation; public class PostConditionInterceptor1 implements Interceptor { public String getname() { return "PostConditionInterceptor1"; public InvocationResponse invoke(invocation invocation) throws Throwable { InvocationResponse rsp = invocation.invokenext(); if (invocation.gettype() == InvocationType.METHOD) { MethodInvocation methodinvocation = (MethodInvocation)invocation; Method method = methodinvocation.method; if ("sqrt".equals(method.getname())) { Double result = (Double) rsp.getresponse(); if (result.doublevalue() < 0) { [...] throw new Error(errorMsg.toString()); return rsp;

14 Qualité de service des applications et POA CHAPITRE Suivant la logique de fonctionnement de la postcondition, l appel de la méthode sqrt est effectué dès le début de l implémentation du code advice (repère ). Le résultat de l appel est récupéré grâce à la méthode getresponse de la classe org.jboss.aop.invocation Response (repère ). Comme pour la précondition, si le résultat est incorrect, une erreur est générée (repère ). Pour la méthode increment, l intercepteur de la postcondition se présente de la façon suivante : package aop.contracts.postconditions; import java.lang.reflect.method; import org.jboss.aop.interceptor; import org.jboss.aop.invocation; import org.jboss.aop.invocationresponse; import org.jboss.aop.invocationtype; import org.jboss.aop.methodinvocation; public class PostConditionInterceptor2 implements Interceptor { public String getname() { return "PostConditionInterceptor2"; public InvocationResponse invoke(invocation invocation) throws Throwable { boolean incrementinvocation = false; int incrementparametervalue = 0; if (invocation.gettype() == InvocationType.METHOD) { MethodInvocation methodinvocation = (MethodInvocation)invocation; Method method = methodinvocation.method; if ("increment".equals(method.getname())) { incrementinvocation = true; incrementparametervalue = ((Integer) methodinvocation.arguments[0]).intvalue(); InvocationResponse rsp = invocation.invokenext(); if (incrementinvocation) { int result = ((Integer) rsp.getresponse()).intvalue(); if (result!= (incrementeparametervalue + 1)) { [...] throw new Error(errorMsg.toString()); return rsp;

15 232 Applications de la POA PARTIE III L implémentation du code advice est à peine plus complexe. Il est nécessaire de sauvegarder les paramètres de la méthode increment c est surtout utile pour les objets dits mutables, ce qui n est pas le cas ici avec un paramètre de type int avant son appel (repère ). Le traitement après l appel est similaire à celui de la postcondition associée à la méthode sqrt (repère ). Paramétrage des postconditions Les deux postconditions se déclarent de la même façon que la précondition précédente dans le fichier jboss-aop.xml : <interceptor-pointcut methodfilter="all" fieldfilter="none" constructorfilter="none" class="aop.contracts.postconditions.postconditionexample1"> <interceptors> <interceptor class="aop.contracts.postconditions.postconditioninterceptor1"/> </interceptors> </interceptor-pointcut> <interceptor-pointcut methodfilter="all" fieldfilter="none" constructorfilter="none" class="aop.contracts.postconditions.postconditionexample2"> <interceptors> <interceptor class="aop.contracts.postconditions.postconditioninterceptor2"/> </interceptors> </interceptor-pointcut> Ce paramétrage n appelle aucun commentaire particulier puisqu il est similaire à celui mis en place pour l implémentation de la précondition. Résultats des exécutions L exécution du premier exemple, mettant en œuvre de manière incorrecte la méthode sqrt, donne le résultat suivant : racine carrée de 4 : 2.0 java.lang.error: Litige sur la postcondition de la méthode sqrt. Le résultat obtenu est négatif (-1.0). [ ] Exception in thread "main" Nous constatons que la valeur de retour a été correctement traitée par la postcondition et qu une erreur a été générée afin d interrompre l exécution du programme.

16 Qualité de service des applications et POA CHAPITRE L exécution du second programme, utilisant une méthode increment contenant une erreur de programmation, aboutit elle aussi à la génération d une erreur : java.lang.error: Litige sur la postcondition de la méthode increment. Le résultat obtenu(1) n'est pas égal à une incrémentation de 1 du paramètre passé à la méthode (1). [ ] Exception in thread "main" Grâce à cette dernière postcondition, le développeur détecte rapidement un bogue pouvant être difficile à percevoir autrement, notamment par la lecture du code, ++p et p++ étant très proches tant scripturalement que sémantiquement. Implémentation des invariants Comme nous l avons vu, il existe deux types d invariants : les invariants de classe et les invariants internes. Les invariants de classe portent sur l état d une classe, en l occurrence la valeur de ses attributs de classe (variables statiques en Java), ou sur l état des attributs de ses instances. La programmation orientée aspect fournit les mécanismes de base permettant de traiter les changements d état. Il est possible d intercepter les modifications des attributs d une classe ou d une instance de classe. Avec JBoss AOP, par exemple, il suffit de créer un intercepteur se concentrant sur les invocations de type InvocationType.FIELD_WRITE. L utilisation de ce mécanisme peut toutefois fortement impacter les performances de l application pour peu que les attributs soient souvent sollicités par les méthodes de la classe, ce qui est généralement le cas. Par ailleurs, la classe peut transiter par un état incohérent lors de l exécution d une méthode, comme nous le verrons dans l exemple fourni plus loin dans cette section. Pour toutes ces raisons, la vérification des invariants de classe s effectue après chaque appel de méthode de la classe. Les invariants de classe deviennent de la sorte des postconditions s appliquant à l ensemble des méthodes d une classe. L implémentation de cette vérification peut se faire sous forme de postcondition pour chacune des méthodes de la classe. Avec JBoss AOP, il suffit de créer un intercepteur unique pour toutes ces méthodes. L existence de cet intercepteur n empêche pas la création d intercepteurs spécifiques pour les méthodes possédant leurs propres postconditions. Afin d illustrer ces particularités, considérons la classe Java suivante représentant un carré : package aop.contracts.invariants; public class Square { private float lowerleftcornerx; private float lowerleftcornery; private float upperrightcornerx; private float upperrightcornery; [...]

17 234 Applications de la POA PARTIE III L invariant de classe évident pour Square est celui vérifiant que les coordonnées des coins inférieur et supérieur gauche sont cohérentes par rapport à la propriété fondamentale d un carré, à savoir que ses côtés sont tous de même longueur. Les méthodes permettant de manipuler un objet de type Square ont besoin de modifier les coordonnées stockées dans les attributs. Lors de l exécution de ce genre de méthode, il n est pas possible de modifier toutes les coordonnées en une seule instruction, l invariant de classe ne pouvant être vérifié à chaque instant. L état de l objet est obligé de transiter par un ou plusieurs états «incohérents», au sens de l invariant, afin de pouvoir effectuer le traitement. L invariant de classe doit donc être implémenté sous la forme d une postcondition s appliquant à toutes les méthodes de la classe Square. Le code suivant montre un exemple de postcondition implémentant un invariant de classe : [ ] public InvocationResponse invoke(invocation invocation) throws Throwable { InvocationResponse rsp = invocation.invokenext(); if (invocation.gettype() == InvocationType.METHOD) { MethodInvocation methodinvocation = (MethodInvocation)invocation; Method method = methodinvocation.method; Object target = methodinvocation.targetobject; int etat = target.getclass().getdeclaredfield("etat").getint(target); if (etat!= 1) { throw new Error("Litige sur l'invariant de classe."); return rsp; [...] Nous constatons d abord que nous avons bien affaire à une postcondition (repère ), l appel à la méthode étant effectué avant la vérification de l assertion. Pour chaque appel de méthode, nous récupérons l instance de classe concernée (repère ) afin d obtenir la valeur de son attribut etat (repère ). Une fois cette valeur obtenue, nous vérifions l invariant (ici, etat doit être égal à 1). Les postconditions implémentant des invariants de classe doivent être testées en dernier, les autres intercepteurs de préconditions et de postconditions étant exécutés avant elles. Avec JBoss AOP, il suffit de déclarer les intercepteurs correspondants en dernier dans la liste des intercepteurs de la coupe définie dans le fichier jboss-aop.xml.

18 Qualité de service des applications et POA CHAPITRE Invariants internes Les invariants internes ne sont pas aisément implémentables avec les outils de la POA. La raison à cela est que leur portée est limitée à un bloc d instruction plus fin que la méthode. Or les outils de POA actuels ne fournissent pas de point de jonction permettant d intercepter efficacement un flot d exécution plus fin que l appel d une méthode. Si nous désirons mettre en place ce type d invariant, le mieux est d utiliser l instruction assert de J2SE 1.4. Le cas des invariants internes démontre que la programmation orientée aspect introduit des fonctionnalités additionnelles par rapport à la programmation orientée objet mais n est pas en mesure de remplacer tous ses mécanismes. Pour aller plus loin Cette section a tenté d illustrer les avantages de la programmation orientée aspect pour implémenter les concepts de base des contrats. Les solutions proposées sont certes encore partielles, et elles mériteraient d être généralisées au travers d un framework évitant le codage en dur des différentes assertions. Par ailleurs, deux particularités restent à traiter : l héritage des contrats et le règlement des litiges. Concernant l héritage des contrats par les classes filles, le problème peut être réglé avec JBoss AOP en créant des intercepteurs héritant de ceux de la classe mère, par exemple. Pour les cas simples, il est possible d utiliser les facilités offertes par le fichier de configuration jboss-aop.xml, notamment en employant la notion de groupe. Pour le règlement des litiges, tout dépend de l application. D une manière générale, les différentes clauses applicables en cas de litige trouvent leur implémentation dans le corps des codes advice. Le test d application Toute application doit être testée afin de garantir à l utilisateur final une qualité de service qui soit satisfaisante, à défaut d être parfaite. On se souvient de l échec du lancement d Ariane 5 dû au dépassement de capacité d une variable dans un programme pourtant soumis à des tests rigoureux. La POA nous permet d'instrumenter le code pour contrôler son exécution. Cette fonctionnalité constitue la brique de base pour implémenter différents outils de test abordés ci-dessous. Il existe deux grandes catégories de test : le test structurel, ou test en boîte blanche ; le test fonctionnel, ou test en boîte noire. Le test structurel vérifie l application en s attachant uniquement à la structure de son code source. L objectif de ce test est d identifier d éventuels problèmes au sein même du code, tels que mauvaises pratiques de programmation, variables ou méthodes non utilisées, etc.

19 236 Applications de la POA PARTIE III Un test structurel classique est le test de couverture, dans lequel l exécution de l application est analysée afin d identifier les portions non couvertes par une campagne de test et donc potentiellement sources d erreur. Le test fonctionnel vérifie que le comportement de l application est conforme aux spécifications des besoins. C est le plus répandu. Il se matérialise sous forme de jeux d essai et de scénarios d utilisation auxquels est confrontée l application. Parmi les divers types de tests fonctionnels, le test de non-régression consiste à exécuter le même scénario sur deux versions différentes d une application généralement la nouvelle et celle qui lui est immédiatement antérieure afin d identifier des comportements divergents non justifiés par ce changement de version (régressions). La programmation orientée aspect propose des outils pour s interfacer étroitement avec une application existante et analyser son exécution. Ces outils sont particulièrement appréciables pour effectuer ces deux des tests. Le test de couverture Comme expliqué précédemment, le test de couverture, aussi appelé analyse de la couverture du code, regroupe différentes méthodes permettant de vérifier que chaque partie d une application est couverte par une campagne de test. On entend par partie couverte le fait que cette partie a été soit exécutée (instruction), soit accédée (variable, attribut, paramètre). Si une partie de l application n est pas couverte, c est qu elle est soit inutile, soit inaccessible, soit non prévue dans les scénarios d utilisation. Analyse de couverture des fonctions La mise en place de test de couverture est assez simple. Il suffit de modifier l application afin que chaque exécution d instruction ou accès à un attribut soit enregistré par l outil d analyse de couverture et que l ensemble des enregistrements soit confronté au code source une fois la campagne de test terminée. On parle alors d analyse de couverture des instructions. Ce type de test repose techniquement sur les points d arrêt d exécution utilisés par les débogueurs. Comme nous l avons vu au cours de la première partie de cet ouvrage, la programmation orientée aspect ne permet pas d intercepter toutes les instructions mais seulement les appels aux méthodes et aux constructeurs ainsi que l accès aux attributs d une classe. Il n est donc possible d implémenter que l analyse de couverture des méthodes, et non celle des instructions. D autres tests de couverture sont décrits de manière synthétique à la page de Steve Cornett dédiée à l analyse de couverture ( Implémentation du test de couverture Un outil de test de couverture est composé de deux éléments : l enregistreur et le comparateur. L enregistreur est chargé d analyser l exécution de l application et d enregistrer

20 Qualité de service des applications et POA CHAPITRE les méthodes appelées et les attributs accédés. Le comparateur confronte ces enregistrements avec le code source afin d identifier les méthodes non appelées et les attributs non accédés. L enregistreur est implémenté grâce aux techniques de la programmation orientée aspect, qui lui permettent d intercepter les appels aux méthodes et les accès aux attributs. Pour le comparateur, la POA n apporte aucune valeur ajoutée, et cet outil peut être très facilement implémenté avec des outils permettant la manipulation et la comparaison de fichiers. Interception des appels aux méthodes et des accès aux attributs L interception des appels aux méthodes et des accès aux attributs se fait très aisément en POA. Le plus difficile consiste à récupérer l ensemble des informations nécessaires au calcul de la couverture. Dans notre cas, il s agit d obtenir la signature de chaque méthode appelée, c est-à-dire la classe d appartenance, le nom, le type de valeur retournée, les types des paramètres et les éventuelles exceptions, ainsi que de chaque attribut accédé (classe, nom et type). Pour accéder à ces informations, les langages de programmation tels que Java ou C# fournissent une API d introspection permettant de lire la structure d une classe, d une méthode ou d un attribut. Ces informations sont enregistrées dans un fichier de traces destiné à être confronté au code source pour identifier les éléments non couverts par la campagne de test. Afin de pouvoir être utilisé dans Microsoft Excel, celui-ci est au format CSV (Comma-Separated Values), ou valeurs séparées par des virgules, chaque valeur d une ligne représentant une colonne. Les colonnes définies sont les suivantes : type d appel ou d accès ; nom de la classe d appartenance de l élément (constructeur, méthode ou attribut) ; nom de l élément ; type (dans le cas d un attribut) ou type de la valeur de retour (cas d une méthode) ; type des paramètres ; exceptions déclarées pour la méthode ou le constructeur. Le code source ci-dessous fournit l implémentation de l intercepteur avec JBoss AOP (pour des raisons de place, seules les parties les plus intéressantes sont reproduites) : package aop.tests.cover; import java.io.filenotfoundexception; import java.io.fileoutputstream; import java.io.printwriter; import java.lang.reflect.constructor; import java.lang.reflect.field; import java.lang.reflect.method; import org.jboss.aop.constructorinvocation;

21 238 Applications de la POA PARTIE III import org.jboss.aop.fieldinvocation; import org.jboss.aop.interceptor; import org.jboss.aop.invocation; import org.jboss.aop.invocationresponse; import org.jboss.aop.invocationtype; import org.jboss.aop.methodinvocation; import org.jboss.util.xml.xmlloadable; import org.w3c.dom.element; public class CoverRecorderInterceptor implements Interceptor, XmlLoadable { private PrintWriter out; public String getname() { return "CoverRecorderInterceptor"; public void importxml(element parameter) { Element t=(element)parameter.getelementsbytagname("record-file").item(0); String filename = ""; if (t!= null) { filename = t.getattribute("value"); if ("".equals(filename)){ throw new RuntimeException("..."); else { throw new RuntimeException("..."); try { FileOutputStream stream=new FileOutputStream(fileName); out = new PrintWriter(stream); catch (FileNotFoundException e) { throw new RuntimeException("..."); out.println("call type,class,name,return / Type,parameters,exceptions"); public void recordmethodcall(string classname, String methodname,class returntype,class[] parameters, Class[] exceptions) { [...] public InvocationResponse invoke(invocation invocation) throws Throwable { String filter = (String) invocation.getmetadata("cover", "filter");

22 Qualité de service des applications et POA CHAPITRE if (filter!= null && filter.equals("true")) { return invocation.invokenext(); InvocationResponse rsp = invocation.invokenext(); InvocationType invocationtype = invocation.gettype(); if (invocationtype == InvocationType.METHOD) { MethodInvocation methodinvocation = (MethodInvocation)invocation; Method method = methodinvocation.method; String classname = method.getdeclaringclass().getname(); String methodname = method.getname(); Class returntype = method.getreturntype(); Class[] parameters = method.getparametertypes(); Class[] exceptions = method.getexceptiontypes(); out.print("method call,"); recordmethodcall(classname,methodname,returntype, parameters,exceptions); else if (invocationtype==invocationtype.constructor) { ConstructorInvocation constructorinvocation = (ConstructorInvocation)invocation; Constructor constructor = constructorinvocation.constructor; String classname = constructor.getdeclaringclass().getname(); String methodname = "N/A"; Class returntype = null; Class[] parameters = constructor.getparametertypes(); Class[] exceptions = constructor.getexceptiontypes(); out.print("constructor call,"); recordmethodcall(classname,methodname,returntype, parameters,exceptions); else if (invocationtype == InvocationType.FIELD_WRITE invocationtype == InvocationType.FIELD_READ) { if (invocationtype == InvocationType.FIELD_READ) { out.print("field read access,"); else { out.print("field write access,"); FieldInvocation fieldinvocation = (FieldInvocation)invocation; Field field = fieldinvocation.field; out.print(field.getdeclaringclass().getname()); out.print(','); out.print(field.getname()); out.print(','); out.print(field.gettype());

23 240 Applications de la POA PARTIE III out.println(); out.flush(); return rsp; [...] La méthode importxml (repère ) est utilisée pour initialiser l intercepteur à partir des informations contenues dans le fichier jboss-aop.xml, en l occurrence le paramètre value du tag record-file définissant le fichier de sortie des résultats. Le détail du paramétrage de l intercepteur est évoqué plus bas. La méthode recordmethodcall (repère ) sert uniquement à écrire les paramètres qui lui sont passés dans le fichier de traces via l attribut out de l intercepteur. Elle est utilisée pour enregistrer les appels aux méthodes et aux constructeurs. La méthode invoke constitue naturellement le cœur de l enregistreur. Celle-ci s assure d abord que l élément sur lequel porte l invocation (méthode, constructeur ou attribut) est pris en compte (repère ). Le critère de décision est fourni par les métadonnées de cet élément, en l occurrence la variable filter du groupe cover, définies dans le fichier jboss-aop.xml. Selon le type d invocation (InvocationType.METHOD, InvocationType.CONSTRUCTOR, InvocationType.FIELD_READ et InvocationType.FIELD_WRITE), la méthode invoke effectue une introspection de l élément pour remplir le fichier de traces. Le traitement des appels de méthode (repère ) est très proche de celui du constructeur (repère ). La seule différence réside dans le fait qu un constructeur n a pas de nom particulier il s agit de celui de la classe et n a pas de valeur de retour. La récupération des informations sur ces deux éléments se fait très simplement par le biais des API Java standards. Le traitement des accès aux attributs d une classe (repère ) différencie les accès en lecture et ceux en écriture afin d identifier d éventuels problèmes d initialisation (accès en lecture) ou de pertinence (accès en écriture). Là encore, l API Java standard est utilisée pour récupérer les informations nécessaires sur l attribut. Mise en œuvre de l enregistreur L exemple simple ci-dessous illustre les résultats obtenus avec notre enregistreur : package aop.tests.cover; public class CoverExample { private static int myfield = 0; public int increment(int value) { return ++value;

24 Qualité de service des applications et POA CHAPITRE public int decrement(int value) { return --value; public static int[] test(object[] t,object j) throws Exception,ArrayIndexOutOfBoundsException { System.out.println("Accès en lecture à myfield : " +myfield); return null; public static void main(string[] args) { CoverExample t = new CoverExample(); System.out.println("Incrémente 1 : "+t.increment(1)); System.out.println("Décrémente 1 : "+t.decrement(1)); try { test(null,null); catch (Exception e) { Cet exemple simple est suffisant pour tester les grandes fonctionnalités de notre enregistreur. Le repère montre que l attribut myfield est accédé en écriture (initialisation à 0) et le repère qu il est aussi accédé en lecture. Le fichier jboss-aop.xml est configuré de la manière suivante : <interceptor-pointcut methodfilter="all" constructorfilter="all" fieldfilter= "ALL" group="cover"> <interceptors> <interceptor class="aop.tests.cover.coverrecorderinterceptor " singleton="true"> <record-file value="d:\\temp\\recordcover.csv" /> </interceptor> </interceptors> </interceptor-pointcut> <class-metadata group="cover" class="aop.tests.cover.coverexample"> <default> <filter>false</filter> </default> <method name="main"> <filter>true</filter> </method> </class-metadata> La coupe (repère ) est définie de manière à concerner l ensemble des éléments interceptables (constructeurs, méthodes et attributs) de sorte à avoir un test de couverture le plus exhaustif possible. Cette coupe concerne le groupe cover, défini plus bas (repère ).

25 242 Applications de la POA PARTIE III L association de l intercepteur à la coupe s accompagne d un tag spécifique à l intercepteur (repère ). Ce tag, traité par la méthode importxml de l intercepteur, fournit à ce dernier le nom du fichier de traces à employer. Des métadonnées sont ensuite associées à la classe CoverExample. Nous spécifions d abord que cette classe appartient au groupe cover (repère ) puis initialisons la variable filter, laquelle est utilisée, comme nous l avons vu à la section précédente, par la méthode invoke de l intercepteur afin d analyser ou non une invocation. Par défaut (repère ), la variable filter est initialisée à false, ce qui signifie qu une invocation doit être analysée. Pour la méthode main (repère ), la variable filter est initialisée à true. Cette méthode étant un passage obligé pour l exécution de la classe CoverExample, il est inutile de l enregistrer dans le fichier de traces. Si nous exécutons maintenant la classe CoverExample, nous obtenons le fichier de traces suivant : Call type,class,name,return / Type,parameters,exceptions Field write access,aop.tests.cover.coverexample,myfield,int Constructor call,aop.tests.cover.coverexample,n/a,n/a,, Method call,aop.tests.cover.coverexample,increment,int,int, Method call,aop.tests.cover.coverexample,decrement,int,int, Field read access,aop.tests.cover.coverexample,myfield,int Method call,aop.tests.cover.coverexample,test,int[],java.lang.object[];java.lang.object,java.lang.exception;java.lang.arrayindexoutofboundsexception Comme nous pouvons le constater, le résultat obtenu avec un éditeur de texte classique n est pas très lisible. Il devient beaucoup plus compréhensible en l ouvrant dans Microsoft Excel, comme l illustre la figure 9.1. Chaque appel et accès a été scrupuleusement enregistré par l intercepteur dans le fichier de traces. Figure 9.1 Fichier de traces de couverture ouvert dans Microsoft Excel Ce résultat constitue le matériel de base pour l analyse de couverture. Il faut utiliser les informations recueillies par l enregistreur et les comparer au code source de l application. Le comparateur n étant pas un domaine de prédilection de la programmation orientée aspect, nous n abordons pas ici la façon de le programmer.