LOG4430 : Architecture logicielle et conception avancée

LOG4430 :Architecture logicielle et conception avancée Applications de base de la conception orientée aspect : surveillance, traçage et profilage

Applications de base de la conception orientée aspect • Contexte • Introduction aux aspects • Conception par aspects • Avantages et inconvénients

1. Contexte • Pensez à la source de tous les maux en génie logiciel ?

1964 1974 1984 1994 2004 Following slides courtesy of Gregor Kiczales, original available at [http://www.cs.ubc.ca/~gregor/papers/kiczales-java-one-04-aop-panel.ppt]

1964 1974 1984 1994 2004 * Shape Display moveBy(int, int) Point Line 2 getX()getY()setX(int)setY(int)moveBy(int, int) getP1()getP2()setP1(Point)setP2(Point)moveBy(int, int) objects are intuitive • Vous pensez intuitivement a des objets ? • Points, lignes… • Surfaces de dessin (Drawing) • GUI Widgets • …

1964 1974 1984 1994 2004 collection of procedures to operate on and manage table entries objects are intuitive objects are not intuitive • En 1969,la plupart des programmeurs auraient utilises la difficile conception et implantation suivante ! +

La programmation par objets Inventée en 1961 A peu près au même moment que la programmation structurée Devient « par objets » en 1967 Rend le code de simulation plus proche du modèle original 1964 1974 1984 1994 2004 OOP intuitive not intuitive

Aparté

Aparté • Ole-Johan Dahl • 12 octobre 1931 – 29 juin 2002 • Norvégien • Père de Simula et de la PPO • Récipiendaire • ACM A.M. Turing Award • IEEE John von Neumann Medal • Développe l’idée de la PPO dans les années 1950 au Centre de calculs norvégien (Norsk Regnesentral) • http://heim.ifi.uio.no/~olejohan/

Aparté • Kristen Nygaard • 27 aout 1926 – 19 aout 2002 • Norvégien • Père de Simula et de la PPO • Récipiendaire • ACM A.M. Turing Award • IEEE John von Neumann Medal • Développe l’idée de la PPO dans les années 1950 au Centre de calculs norvégien (Norsk Regnesentral) • http://en.wikipedia.org/wiki/Kristen_Nygaard

1964 1974 1984 1994 2004 OOP intuitive • Qu’est-ce la programmation par objets ? • Une façon de penser • Objets, classes, hiérarchies • Des mécanismes de soutient de cette pensée • Classes, interfaces, encapsulation, polymorphisme • Une façon de • Rendre le code plus proche de sa conception • Améliorer la modularité de la conception et du code • Avec de nombreuses implantations • Styles, bibliothèques, extension ad-hoc…

1964 1974 1984 1994 2004 1 * Shape Display moveBy(int, int) Point Line 2 getX()getY()setX(int)setY(int)moveBy(int, int) getP1()getP2()setP1(Point)setP2(Point)moveBy(int, int) OOP MVC Observer Pattern • Bonne modularité de la conception mais faible modularité de l’implantation class Pointextends Shape { privateint x = 0, y = 0; int getX() { return x; } int getY() { return y; } void setX(int x) { this.x = x; display.update(this); } void setY(int y) { this.y = y; display.update(this); } }

1964 1974 1984 1994 2004 AOP OOP MVC Observer Pattern • Pendant ce temps la… • Début des années 80 (peut-être même plus tôt) • D’autres travaillaient • Structure « entrecoupantes » • Mécanismes • Réflexion comportementale • MOP • Programmation orientée sujets • Le terme « programmation par aspects » apparaît en 1997

1964 1974 1984 1994 2004 OOP AOP * Shape Display moveBy(int, int) Point Line 2 getX()getY()setX(int)setY(int)moveBy(int, int) getP1()getP2()setP1(Point)setP2(Point)moveBy(int, int) aspect ObserverPattern { private Display Shape.display; pointcut change(): call(void figures.Point.setX(int)) || call(void Point.setY(int)) || call(void Line.setP1(Point)) || call(void Line.setP2(Point)) || call(void Shape.moveBy(int, int)); after(Shape s) returning: change() && target(s) { s.display.refresh(); }} 1 ObserverPattern

1964 1974 1984 1994 2004 OOP AOP • Maintenant, est-ce que vous pourriez appeler une classe « ObserverPattern » ?

1964 1974 1984 1994 2004 OOP AOP • Qu’est-ce la programmation par aspects ? • Une façon de penser • Aspects, structures entrecoupantes • Des mécanismes de soutient de cette pensée • Points de jointure, points de coupe, « advice » • Une façon de • Rendre le code encore plus proche de sa conception • Améliorer la modularité de la conception et du code • Avec de nombreuses implantations • Styles, bibliothèques, extension ad-hoc…

1. Contexte • Autres aspects ? • Patron de conception • Sureté des fils d’exécution Swing • Application de politiques • Authentification, synchronisation… • Gestion des transactions • Débogage • Logging • …

1. Contexte • IBM rapporte • Implémentation de politiques • 15 à 30% d’amélioration de la qualité • Gains en productivités significatifs • Popularisation de logiciels complexes • De nouvelles opportunités d’affaires

Un premier exemple public class ClasseDuModel { … attributs pour la logique de la classe … attributs pour l’authentification, … vérification des contrats et profilage public void uneMethode { // authentification // vérifier les pré conditions // enregistrer l’entrée dans l’opération … accomplir les opérations // authentification // / vérifier les post conditions // enregistrer la sortie de l’opération } // autres méthodes } Dans cet exemple, authentification, vérification des contrats et profilage sont croisés avec la méthode qui accomplie des fonctions reliées à la logique de la classe 2.Introduction aux aspects

A noter… Deux problèmes sont à noter ici: L’implémentation d’authentification, vérification des contrats et profilage n’est pas localisée Le code source est dispersé probablement dans beaucoup d’autres méthodes, classes, paquetages L’implémentation de uneMethode() fait beaucoup plus que ce qu’elle devrait Elle contient du code source concernant plusieurs préoccupations

Symptômes de l’intrication (entrecroisement) L’entrecroisement de concepts est relié à deux symptômes dans le développement logiciel: Dispersion de code source (code scattering): implémentation de concepts qui ne sont pas bien modulaires et qui sont dispersés dans le système. Croisement de code source (code tangling): un module peut contenir des parties de code concernant plusieurs concepts. Dispersion et croisement sont deux aspects différents du même problème.

D’où vient l’intrication? Il n’existe pas nécessairement une correspondance un-à-un du domaine du problème au domaine de la solution L’espace des requis est multidimensionnel alors que l’espace de l’implémentation est unidimensionnel (en programmation orientée objets chaque classe doit avoir une seule responsabilité) Implementation Requis R1 C1 R2 C2 R3 C3 R4 C4 dispersion croisement

Entrecroisement des aspects technique -nous aimerions que le diagramme se transforme… Composant Composant Composant

…en celui-ci! Aspects Composant Composant Composant Nous avons besoin d’un nouveau module pour pouvoir résoudre le problème d’entrecroisement.

Principes de la POA “AOP can be understood as the desire to make quantified statements about the behavior of programs, and to have these quantifications hold over programs written by oblivious programmers. » Robert E. Filman and Daniel P. Friedman • Deux concepts • Quantification • Obliviousness

Principes de la POA: 1. « Quantification » “Dans programme P, quand condition C est évaluée à vrai, exécute action A.” quand exécution atteint ce point… …ou ce point… …exécute ce code! C1 C2 C3

Les points dans C2 et C3 ne sont pas choisis au hasard; ils doivent être bien définis Un point d’insertion ou de jonction (joinpoint) est un point dans le programme bien défini. Exemple: appel/exécution d’une méthode. A C1 C2 C3

Composant, aspects et points d’insertion Les points d’insertion sont les endroits où les aspects interagissent avec le reste du système. Source: [Bardou, ’98]

Principes de la POA: 2. « Obliviousness » A noter que ni C2 ni C3 font des appels de A ! Même si les composants C2 et C3 ont été enrichis avec le comportement fourni par l’aspect A, ils ne sont pas au courant qu’un tel enrichissement existe – ils n’ont subit aucune modification pour s’adapter à cet enrichissement. Différence avec les appels de méthodes usuels. A C1 C2 C3

Implémenter un programme orienté aspects Deux étapes: Décomposition: Identifier et implémenter les fonctionnalités de base (classes) et les concepts entrecroisés (aspects) Exemples d’aspects: authentification, vérification de contrats, profilage, sauvegarde de données. Définir les règles d’interaction entre les fonctionnalités de base et les concepts entrecroisés

Finalement… public class BusinessLogic { … data members for business logic public void someOperation { … perform core operation } // more operations similar to the above } public aspect Authenticator { … data members for authentication public void authenticate() {…} } Compilateur public aspect Logger { … data members for logging public void log() {…} } public aspect ContractChecker { … data members for contract checking public boolean precondition() {…} public boolean postcondition(){..} }

Plus précisément… • Tissage d’aspects • À la compilation • Comparer avec une compilation « traditionnelle »

Avantages de la POA • En comparaison avec la programmation orientée objets: • Une séparation nette des préoccupations – espace bidimensionnel du domaine de l’implémentation • Code source moins dispersé et moins croisé • Meilleure modularité: il est plus facile de analyser, déboguer, changer et réutiliser les modules • Une maintenance plus facile • La POA ne se limite pas à la POO. • AspectL • Aspect-C

AspectJ – POA pour Java • AspectJ est une extension à Java qui fournit les moyens pour faire de la POA • AspectJ est un sur-ensemble de Java. • Chaque programme valide de Java est aussi un programme valide d’AspectJ

Exemple: Mémoire tampon limitée La classe Buffer contient deux types de méthodes: Ceux qui modifient son état: put(), get() Ceux qui le consultent seulement: isFull(), isEmpty() public class Buffer { private String[] BUFFER; int putPtr; // keeps track of puts int getPtr; // keeps track of gets int counter; // holds number of items int capacity; Buffer (int capacity) {…} public boolean isEmpty() {…} public boolean isFull() {…} public void put (String s) {…} public String get() {…} } }

Comportement de la classe Buffer • public class Buffer { • … • public void put (String s) { • if (isFull()) • System.out.println("ERROR: Buffer full"); • else { • BUFFER[putPtr++] = s; • counter++; • } • } • public String get() { • if (isEmpty()) • return "ERROR: Buffer empty"; • else { • counter--; • return BUFFER[getPtr++]; • } • } • }

AspectJ language concepts • Point de jonction (joinpoint): un point bien défini dans l’exécution d’un programme • Exemple: appel de la méthode get() de la classe Buffer • Point d’action (pointcut): Un ensemble de points de jonctions. • Exemple: l’exécution de toutes les méthodes modifiant l’état de la classe Buffer • Greffon (advice): Un block qui spécifie le code à exécuter quand un point d’action a été atteint • Exemple: avant l’appel de la méthode get(), affiche un certain message

But: afficher un message avant chaque appel de la méthode put() et de la méthode get() de la classe Buffer Comment: Définir un point de jonction. Le point de jonction suivant se réfère à une méthode publique dont le type de retour est vide, dont le nom est « put » et qui prend une chaîne de caractères en paramètre: call(public void Buffer.put(String)) Ce point de jonction représente le moment d’exécution après l’évaluations des paramètres mais avant que la méthode soit appelée Exemple: Profilage

Identifier des points de jonction • Le point de jonction suivant se réfère à chaque appel de la méthode « get » sans paramètres et dont le type de retour est une chaîne de caractères et dont la visibilité est « public » call (public String Buffer.get())

Définir un point d’action • Le point d’action suivant définit un point d’action dont le nom est « mutators » et qui sera activé si l’un des points de jonction précédemment définis est satisfait pointcut mutators(): call(public void Buffer.put(String)) || call (public String Buffer.get());

Le greffon définit le code à exécuter quand un point d’action est activé. Un greffon est donc défini par rapport à un point d’action Le type de greffon doit aussi être spécifié. Dans ce cas, le greffon sera exécuter avant ce qui est référé par le point d’action Définir un greffon before(): mutators() { System.out.println("------ Mutator method called."); }

Il existe trois façons d’associer un greffon à un point d’action: • before: s’exécute juste avant le point d’action • after: s’exécute juste après le point d’action • around: s’exécute à la place du code qui est référé par le point d’action. • Donne la possibilité d’exécuter le code défini par le point d’action en plus en appelant proceed()

Définir un aspect • Un aspect est un module • Il définit ses points d’action et ses greffons public aspect Tracer { pointcut mutators(): call(public void Buffer.put(String)) || call (public String Buffer.get()); before(): mutators() { System.out.println("------ Mutator method called."); } }

Profilage ? Quelle serait la sortie du programme ??? public class BufferDemo { public static void main(String[] args) { Buffer buffer = new Buffer(10); buffer.put("Hello"); buffer.put("there"); System.out.println(buffer.get()); System.out.println(buffer.get()); } } public aspect Tracer { pointcut mutators(): call(public void Buffer.put(String)) || call (public String Buffer.get()); before(): mutators() { System.out.println("------ Mutator method called."); } }

Profilage ------ Mutator method called. ------ Mutator method called. ------ Mutator method called. Hello ------ Mutator method called. there public class BufferDemo { public static void main(String[] args) { Buffer buffer = new Buffer(10); buffer.put("Hello"); buffer.put("there"); System.out.println(buffer.get()); System.out.println(buffer.get()); } } public aspect Tracer { pointcut mutators(): call(public void Buffer.put(String)) || call (public String Buffer.get()); before(): mutators() { System.out.println("------ Mutator method called."); } }

Types de points de jonction Appels de méthodes et constructeurs Exécution de méthodes et constructeurs Accès à un attribut Gestion des exceptions Initialisation d’une classe Structure lexicale Flux de control Objets visés et arguments Tests de conditions

Appels de méthodes et constructeurs call (public void MyClass.myMethod(String)) Appel à myMethod() de MyClass prenant un argument de type String, retournant void, avec visibilité public call (void MyClass.myMethod(..)) Appel à myMethod() de MyClass prenant tout type d’arguments, dont le type de retour est void, peu importe la visibilité call (* MyClass.myMethod(..)) Appel à myMethod() de MyClass prenant tout type d’arguments, retournant n’importe quel type. call (* MyClass.myMethod*(..)) Appel de toute méthode dont le nom commence avec “myMethod” de MyClass.

call (* MyClass.myMethod* (String,..)) Appel à toute méthode dont le nom commence avec “myMethod” de MyClass et dont le premier argument est de type String call (* *.myMethod(..)) Appel à myMethod() de n’importe quelle classe dans le paquetage default call (MyClass.new()) Appel au constructeur de MyClass qui ne prend pas d’arguments call (MyClass.new(..)) Appel au constructeur de MyClass avec n’importe quels types d’arguments

call (MyClass+.new(..)) Appel au constructeur de MyClass ou un de ses enfants, dont les types d’arguments ne sont pas importants call (public * com.mycompany..(.*(..))) Appel à toute méthode public dans chaque classe de n’importe quel paquetage dont le paquetage racine est com.company

LOG4430 : Architecture logicielle et conception avancée